cabacon
You (and another respondent) both cite the case where someone unthinkingly generates a large swath of text using the LLM, but that's not the only modality for incorporating LLMs into writing. I'm with you both on your examples, fwiw, I just think that only thinking about that way of using LLMs for writing is putting on blinders to the productive ways that they can be used.
It feels to me like people are reacting to the idea that we haven't figured out how to work it into our pedagogy, and that their existence hurts certain ways we've become accustomed to measuring people having learned what we intended them to learn. There's certainly a lot of societal adaptation that should put guardrails around their utility to us, but when I see "They will make us dumb!" it just sets of a contrarian reaction in me.
So, I guess I'm just saying that LLMs are a tool like any other. Their existence doesn't make you worse at what they do unless you forgo thinking when you use them. You can use a calculator to efficiently solve a wrong equation - you have to think about what it is going to solve for you. You can use an LLM to make a bad argument for you - you have to think about the inputs you're going to have it output for you.
I was just feeling anti-alarmist-headline - there's no intrinsic reason we'd get dumber because LLMs exist. We could, but I think history has shown that this kind of alarmism doesn't come to fruition.
I have heard people argue that the use of calculators (and later, specifically graphing calculators) would make people worse at math; quick searching found papers like https://files.eric.ed.gov/fulltext/ED525547.pdf discussing the topic.
I can't see how the "LLMs make us dumber" argument is different than those. I think calculators are a great tool, and people trained in a calculator-having environment certainly seem to be able to do math. I can't see that writing has done anything but improve our ability to reason over time. What makes LLMs different?
In addition, the performance engineers tend to be employed by the facilities, not the computational scientists. They're the ones who do a bunch of legwork of profiling the existing code on their new platform, and figuring out how to squeeze any machine-specific performance out of the code.
A lot of these codes are time-marching PDE solvers that do a bunch of matrix math to advance the simulation, so the kernel of the code is responsible for a vast majority of the time spent during a job. So it's not necessarily a huge chunk of code that needs to be tuned to wring better performance out of the machine.
The parallel communication they do is also to an API, not an ABI - the supercomputing vendors drop in the optimizations in the build of the library for their machine, to take advantage of network-specific optimizations for various communications patterns. If you express your code in the most-specific function (doing a collective all-to-all explicitly, say, rather than building your own all-to-all out of the point-to-point primitive) the MPI build can insert optimized code for those cases.
There's some misalignment because the facility will be in the top 500 for a few years, while the code lives on and on and on. If your supercomputer architecture is really out of left field (https://en.wikipedia.org/wiki/Roadrunner_(supercomputer)) it's not going to be super worth it for people to try to run on it without porting support from the facility.
Then as things shifted back to linear depreciation, it made building/running malls much less attractive, and we're seeing that play out over the 20-30 year capital lifecycle you mention.
It was unpopular, to say the least. Your personal belongings went into a pedestal on wheels that you could take to whichever workspace you wound up at that day. This was in 2000/2001 or so.
In hindsight, I wish I'd had enough experience with the question and possible scenarios to ask for a second answer from people in the first org; I suspect there were more good answers available, but one obvious answer that everyone snapped to first.
If you're looking for cross-team health, maybe you could adapt it to "Tell me about someone on the other team that you admire?"
As a contrived example, if you've got a microservice that provides data FOO about a request that isn't actually end-user critical, you can mitigate your dependency on it by allowing your top-level request to succeed even if the FOO data is missing. Or maybe you can paper over blips of unavailability with cached data.
But, yes, know what you depend on and how reliable they are, then see if you need to take more action than that if your target is higher than the computed target.
The queue are everywhere - your messaging queue, the threadpool, the hardware threads, and other layers of the stack and APIs you use. The video adds the interesting detail that as you add more tellers (workers) you learn of impending disaster only in the outlier p99 (or higher) latencies; by the time your p85 latency rises, you're already about to stall out.
Other aiming-for-HPC languages include co-array Fortran (http://en.wikipedia.org/wiki/Coarray_Fortran) and Unified Parallel C (http://en.wikipedia.org/wiki/Unified_Parallel_C).
I never really saw any of them while working in HPC, though. It was just Fortran, C, and sometimes Python. The Python would really just call out via SWIG to a C function for the numeric kernel.
As some recreational reading, less suiting the original request, I very much enjoyed David Foster Wallace's 'Everything and More: A Compact History of Infinity' (http://www.amazon.com/Everything-More-Compact-History-Infini...). DFW is not for everyone, but I enjoyed it a lot. Maybe just check it out of the library first to see if it's for you.
Make: Article on Novena
And, of course, with Go you have a nice progression from learning to play on the 9x9 board for tactics, the 13x13 board to begin learning strategy, and the 19x19 board to play the real game. And thanks to the handicapping system, you can play much stronger players with both of you playing your hardest and both with a chance to win.
He comments on professional matches, but the part of his feed that I enjoy are the 1/3/5 minute time control games he plays. He is very good at articulating his thoughts during the game, and I find that much more engaging that listening to analysis of alternate lines that's more common in commentated chess matches.
I learned the alternating esotropia name from my parents, probably during high school or so. I don't think I was able to name it before that, and I don't remember the context in which they shared it. Probably I was complaining about the stereograms that were popular at the time; I have never been able to see anything in those.
Aside from what I've mentioned so far, I also get a free bonus of driving my wife a little crazy; she always tries to figure out which of my eyes I'm looking out of when we're talking face-to-face. It's nice to have a bit of novelty that is, all-in-all, not really that big of a deal. It's fun to talk about, though, as evidenced by the popularity of this thread.
I have played ultimate frisbee for years quite successfully, and people were usually surprised when I mentioned I have no depth perception. I've met another A.E. person who was a good softball player. The hard part is when I have to look up at blue sky to catch something; the size difference between "can jump to catch it and cannot" is not very big, and there are no parallax/overlapping cues to draw on.
Interestingly, one friend said "Oh, that explains it" when he learned about my eyes. He noticed that I never look into a cup or glass straight-on when filling it, but instead look at it from the side so I can see how full it is. The growth of the circle of the top-of-liquid is small enough that I will heavily underfill a glass rather than risk spilling. As you suggest, it's not deep life-changing stuff, but it is quite a novelty!
My sensation was that given the size of the thing, it should not all have fit in front of me. That is, given how far away the back was, and how large it looked, the front of it should have been behind my head, but it wasn't. In a later meeting with a visual specialist, we confirmed that this was typical for people who haven't experienced 3d to feel about 3d. We also convinced ourselves that there was no way for me to get that with just corrective lenses.
How fun for this tech to hit the mainstream! For reference, the older tech was based on, I believe, the CAVE stuff (http://en.wikipedia.org/wiki/Cave_automatic_virtual_environm...)
I don't think I would have been as interested in reading this (interesting!) book if I hadn't seen the power of things like NERDTree and TagBar, and I wouldn't have seen those if I hadn't poked through Janus.
Outside of that, http://yanpritzker.com/2011/12/16/learn-to-speak-vim-verbs-n... has a nice explanation of the editing worldview, which ties in with Steve's quote in http://learnvimscriptthehardway.stevelosh.com/chapters/16.ht..., "The idea of operators and movements is one of the most important concepts in Vim, and it's one of the biggest reasons Vim is so efficient. We're going to practice defining new motions a bit more, because extending this powerful idea makes Vim even more powerful."
Check out http://www.moolenaar.net/habits.html, http://stackoverflow.com/questions/1218390/what-is-your-most..., and maybe http://vimcasts.org/episodes/archive?
I've been using it for about a decade, so I think I've lost the beginner's mind to evaluate whether these are really the right entry points. Lots of people are passionate about vim, though; some googling should find you the exercises that will help you the most.
For myself, I knew core-vim pretty well, and was coming back to it after taking textmate and sublime text for a spin. Janus was a fast way to bolt on the IDE-alikes I liked from ST2. It was, indeed, too much on a first go, and I uninstalled it. I am back to it, though, and appreciate that it brought together the "big guns" like fugitive, nerdtree, syntastic, &c. as well as things I'm not sure I would have found, like Tim Pope's excellent unimpaired plugin.
Doing things like vimtutor is great for a newbie, but I don't think I care as much whether they have Janus installed or not while they do it.
For my part, I enjoyed the semantic markup it gave for something as big as a book, with auto-generating index and glossary as well. It's a lot of work, but the output reflects it. Looking at the HTML in the first chapter there, the spans with "term" and "menuitem" make me think something like docbook is going on behind this too.