I have a kid in high school who uses LLMs to get feedback on essays he has written. It will come back with responses like "you failed to give good evidence to support your point that [X]", or "most readers prefer you to include more elaboration on how you changed subject from [Y] to [Z]".
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.
I guess my point is that the argument being made is "if you lift dumbbells with a forklift, you aren't getting strong by exercising". And that's correct. But that doesn't mean that the existence of forklifts makes us weaker.
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.
Plato's _Phaedrus_ features Socrates arguing against writing; "They will cease to exercise memory because they rely on that which is written, calling things to remembrance no longer from within themselves, but by means of external marks."
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?
I worked at a supercomputing facility for a few years. The codes are typically decades old, maintained by hundreds of people over the years. By and large, they understand their performance profiles, and are working to squeeze as much out of the code as they can.
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.
You might enjoy http://www.iquilezles.org/live/ where he live codes some ray-marching using some kind of opengl editor. It's not quite what you're talking about, since it's just running the opengl code, but you could imagine it going through some kind of compiler/visualizer pipeline like you're thinking about.
Yes, absolutely. They did something like this at the Sun Microsystems field office outside of Chicago while I worked there. You would log into a sunray with your smartcard and pick up whatever you had left behind in your session, with no permanent desk assignment.
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.
Truth be told, I don't think I'm calibrated on the question yet; I've only used it twice. In one org, there was a shining star who attracted all the answers. In the other org, someone laughed because of the number of good answers, and started rattling off names and reasons.
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.
My favorite interviewing question as an IC was "Tell me about someone on your team you admire". It let me learn about what people valued based on why people were admired, and gave some depth-of-bench sense whether there were lots of distinct names, or if everyone was in awe of the one good person on the team.
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?"
Regarding "theoretical best", I think that is "in the absence of mitigations". I think you can build a service with a higher SLA than one of its dependencies, but only if you recognize that impedance mismatch and build in defenses.
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.
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.
I clicked on this topic in order to make this suggestion. To expand on it a little bit, I was a math major and read Spivak's 'Calculus' after I had already taken real analysis. I found it delightful - it really approaches the topics from first principles and unlike many calculus textbooks actually goes through the effort of presenting proofs of the theorems. Highly recommended.
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.
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 mean, the J Software app is basically that, although J instead of APL. The terseness makes for a pretty good programming environment despite the slow input speed of the virtual keyboard. You don't get the unicode APL customisation you're talking about, but it's pretty close.
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.