I found your example of a joke child made very interesting - me a good jokes is something that brings is unexpected perspective on things while highlighting some contradictions in one world models.
In the adult would model there is absolutely no contradiction about the joke you mention - it’s just a bit of cute nonsense.
But in a child’s world this joke might be capturing the apparent contradiction - the sky is “in the tree”, so it must have climbed it, to be there (as they would have to do), yet they also know that the sun is already in the sky, so it had absolutely no reason to do that. Also, “because it’s already there” - which is a tricky idea in itself.
We take planetary systems and algebra and other things we can’t really perceive as granted, but a child model of the world is made of concrete objects that mostly need a surface to be on, so the sun is a bit of a conundrum in itself! (Speaking of my own experience remembering a shift from arithmetics to algebra when I was ~8).
If not too much of a personal question - I would love to hear what your child would answer to a question why she finds that joke funny. And whether she agrees with my explanation why it must be funny :-)
This is a super apt analogy. Every time I decided to let LLMs “vibe-fix” non-obvious things for the sake of experiment, it spiraled into an unspeakable fubar territory, which needed to be reverted - a very similar situation to this financial collapse.
Invariably, after using the brain, the real fix was usually quite simple - but, also invariably - was hidden behind 2-3 levels of indirection in reasoning.
On the other hand, I had rather pleasant results when “pair-debugging”, my demanding to explain why or just correcting it in the places when it was about to go astray certainly had effect - in return I got some really nice spotting of “obvious” but small things I might have missed otherwise.
That said, definition of “going astray” varies - from innocently jumping into what looked like unsupported conclusions to blatantly telling me something was equal to true right after ingesting the log with the printout showing the opposite.
My favourite story of that involved attempting to use LLM to figure out whether it was true or my hallucination that the tidal waves were higher in Canary Islands than in Caribbean, and why; it spewed several paragraphs of plausibly sounding prose, and finished with “because Canary Islands are to the west of the equator”.
This phrase is now an inner joke used as a reply to someone quoting LLMs info as “facts”.
It was Claude in November 2024, but the “west of equator” is a good enough universal nonsense to illustrate the fundamental issue - just that today it is in much subtler dimensions.
A not-so-subtle example from yesterday: Claude Code claiming to me yesterday assertion Foo was true, right after ingesting the logs with the “assertion Foo: false” in it.
I think it got backgrounded. I'm talking about the first big push, early 90s. I remember lots of handwringing from humanities peeps that boiled down to "but just anyone can write a web page!"
I don't think it changed, I do think people stopped talking about it.
The web remains unreliable. It's very useful, so good web users have developed a variety of strategies to extract and verify reliable information from the unreliable substrate, much as good AI users can use modern LLMs to perform a variety of tasks. But I also see a lot of bad web users and bad AI users who can't reliably distinguish between "I saw well written text saying X" and "X is true".
Yes, it still isn't, we all know that. But we all also know that it was MUCH more unreliable then. Everyone's just being dishonest to try to make a point on this.
3. https://www.intel.com/content/www/us/en/developer/articles/t... - shows you whether the above is matching the reality (besides the CPU alone, more often than not your bottleneck is actually memory accesses; at least on the first access which wasn’t triggered by a hardware prefetcher or a hint to it. On Linux it would be staring at “perf top” results.
So, the answer is as is very often - “it depends”.
I agree on "it depends". And usually not only on your actual code and data, but also how you arrange it over cache lines, what other code on the same core/complex/system is doing to your view of the cache and some other internal CPU features like prefetchers or branch predictors.
...and we always circle back to "premature optimization is the root of all evil", since processors are a wee bit more intelligent with our instructions than we thought. :)
Not that intelligent. If you have two loads and one store per cycle, then that’s it. (Recall that we have SSDs with 14 GB/s sequential reads now, yet CPU clocks are below 6 GHz.) Most of the computational power of a high-performance CPU is in the vector part; still the CPU won’t try to exploit it if you don’t, and the compiler will try but outside of the simplest cases won’t succeed. (Most of the computational power of a high-performance computer is in the GPU, but I haven’t gotten that deep yet.)
I don’t mean to say that inefficient solutions are unacceptable; they have their place. I do mean to say that, for example, for software running on end-users’ computers (including phones), the programmer is hardly entitled to judge the efficiency on the scale of the entire machine—the entire machine does not belong to them.
> We should forget about small inefficiences, say 97% of the time; premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified.
D. E. Knuth (1974), “Structured Programming with go to Statements”, ACM Comput. Surv. 6(4).
You are right, but with a good optimizing compiler and out of order execution, your code will not work the way you guess most of the time, even though it accomplishes what you want.
On the other hand, while doing high performance compute, the processor will try to act smart to keep everything saturated. As a result, you still need to look at cache trash ratio, IPC, retirement ratio, etc. to see whether you are using the system at its peak performance, and again CPU is doing its thing to keep the numbers high, but that's not enough of course. You have to do your own part and write good code.
In these cases where you share the machine (which can be a cluster node or a mobile phone), maximizing this performance is again beneficial since it allows smoother operation both for your and other users' code in general. Trying to saturate the system with your process is a completely different thing, but you don't have to do that to have nice and performant code.
GPU computation is nice, and you can do big things fast, but it's not suitable for optimizing and offloading every kind of task, and even if though the task is suitable for the GPU, the scale of the computation still matters, because a competent programmer can fit billions of computations until a GPU starts running your kernel. The overhead is just too big.
Knuth's full quote doesn't actually invalidate me, because that's how I operate while writing code, designed for high performance or not.
Wait until you learn the Tomasulo algorithm is not a magic wizard box for fast code, but that you can also write code that meshes well with it and get even more performance. Your CPU can run up to 5ish instructions every cycle - are you giving it instructions in suitably matched groups to maximize parallelism?
Premature optimization may be the root of all evil, but timely optimization can give you insane benchmark numbers, at least. Not enough people pay attention to the word "premature" and they think it's about all optimization. Sadly, I've never worked on anything where it would have been timely. Haven't even used SIMD. Just watched other people's talks about it.
Some general principles are widely applicable: modern processors love to work on big linear SIMD-aligned arrays of data. Hence you have the structure-of-arrays pattern and so on. While a CPU is still the best tool you have for complex branching, you should avoid complex branching as much as possible. In Z80-era architectures it was the reverse - following a pointer or a branch was free, which is why they invented things like linked lists and virtual functions.
I have written a boundary element method based material simulation code in my Ph.D., and had time and opportunity to apply both good design practices and some informed coding such as minimum and biased branching (so the code runs unimpeded for most of the time), lockless algorithms and atomics in parallel code where applicable. Moreover I looked for hotspots with callgrind, and checked for leaks with valgrind.
As a result, I was handling two 3000x3000 (dense and double precision floating point) matrices and some vectors under ~250MB RAM consumption, and getting in an out of whole integration routine under a minute. Whole evaluation took a bit more than a minute in last decade's hardware.
Perf numbers returned great. ~5IPC, 20% cache trash, completely and efficiently saturated FPU and memory bandwidth.
Result? The PoC was running in 30 minutes, my code was run and done under 2 minutes for most problems. The throughput was 1.7 million complete Gaussian Integrations per second, per core. We have an adaptive approach which takes many partial integrations for a one complete integration [0], so it amounted to a higher number of integrations (IIRC it was ~5 mil/sec/core, but my memory is hazy.).
The code I have written doesn't call for SIMD explicitly, but Eigen [1] most probably does for Matrix routines. Nevertheless, the core "secret sauce" was not the formulae but how it's implemented in a way which minds for the processor's taste. Adding "-march native -mtune native -O3 -G0" gave a 3x performance boost in some steps of the code.
Currently slowly reimplementing this in a tighter form, so let's see how it goes.
So, also considering what I do for a job, I know how nuanced Knuth's quote is, but people are people, and I'm not the one who likes to toot his horn 7/24/365.
I just wanted to share this to confirm, validate and support your claim only, and to continue conversation if you are interested more in this.
Indeed, scheduling instructions into parallel-compatible aligned blocks is menial work that's usually best done by a machine; each CPU has different preferences, so it only works well if the machine knows which kind of CPU the code will actually run on.
Eigen certainly uses a bunch of optimizations, including SIMD, but also things like FFTs and matrix decompositions.
Try “3M earplugs yellow” on amazon. They are pretty much fully immersed in the ear (for me), and the insulation is very good. The pressure - yeah it took maybe a few days to get used to, but…
The effects for me (living in Brussels city centre, so quite noisy - police, ambulance, sometimes loud tourists past midnight, and a bit of construction at 6am nearby to keep it real :-) ) were very pronounced:
From needing 9 hours and feeling groggy in the mornings anyway, to easily going on 7-8, feeling very refreshed and alert each day.
A cool side effect was that this superpower works also while traveling - so, I no longer care how noisy the airco is in the hotel room, being next to the lift, or having the window above the lively bar.
The only downside with those earplugs that they are good maybe for 3-4 nights and then are too squished to be useful; but the upsides more than make it up for me.
I've tried the squishy foam earplugs, and they always fall out. Other suggestions, such as silicone and custom earplugs, are something I'm going to try. Let's see if they help.
However, what destroys my sleep is the light from early morning, streetlights, and the neighbor's porch light. Unfortunately, our bedroom faces southeast and features French doors that open onto an east-facing three-season porch, allowing sunlight to stream in. Yeah, I've got curtains everywhere, and I have room-darkening curtains on order. If those don't work, the next step is putting solar panels over my bedroom windows. I figure if I'm going to keep light out, I might as well put it to work some other way.
As an experiment, I'm using my car camping mattress in my office, which is the quietest room in the house, and I'm blocking the light from the windows with curtains and cardboard. So far, it's the best sleep I've had in years. There's a bit of domestic disharmony now, but hopefully my partner and I can work out a compromise on light-blocking curtains and keeping them fucking shut.
Have you tried a blackout sleep mask? I had to try a few to find one which consistently stays in place overnight and doesn't put any pressure on my eyes, but once I found one it solved all light-related problems for me.
I've tried them, and they don't work for me. They trigger a bit of claustrophobia. I sleep with a full-face CPAP mask, and I'm not sure I can take anything more strapped to my face.
My wife started snoring pretty badly while she was pregnant so ended up buying these earplugs https://www.amazon.com/dp/B0DPH7HNT1. I've never been able to sleep in the foam earplugs as they either fall out or the pressure starts to really irritate after a while, but these don't put pressure and they stay in all night. They're also really block out noise.
Nice. Which model do you use? And do they sell them in the U.S.? Not that I would mind making a trip overseas and getting away from the insanity here for a little while, but it adds to the cost.
I have the "Relax & Sleep" pair. I got mine from a Finnish reseller, and thought they were a global company but they seem to list only European locations. I believe thomann.de delivers to the U.S., but that's little help since the point of these would be to get them made individually.
I would assume that your local audiologist or music instrument store will know what the U.S. equivalent to these is. It seems to me that Elacin's biggest market is musicians who want a comfortable pair of earplugs with a flat frequency response.
It's rare for me to encounter another Belgian on HN but I'll definitely try this.
Sleeping roadside till i have my upper floor renovated has been a disaster for my sleep and functioning.
Same thing with PNG. Just call the format with new additions it PNGX, so the user can clearly see that the reason their software can’t display the image is not a file corruption.
This is just pretending that if you have a cat and a dog in two bags and you call it “a bag”, it’s one and the same thing…
There might be another factor at not using the debugger beyond the pure cluelessness: often you can’t really run it in production. Back when I started with coding (it was Turbo Pascal 3.0, so you get the idea :-), I enjoyed the use of the debugger quite a lot.
But in 2000 I started working in a role which required understanding the misbehavior of embedded systems that were forwarding the live traffic, there was a technical possibility to do “target remote …” but almost never an option to stop a box that is forwarding the traffic.
So you end up being dependent on debugs - and very occasional debug images with enhanced artisanal diagnostics code (the most fun was using gcc’s -finstrument-function to catch a memory corruption of an IPSec field by an unrelated IKE code in a use-after free scenario)
Where the GDB shined though is the analysis of the crash dumps.
Implementing a “fake” gdb stub in Perl, which was sucking in the crash dump data and allow to leisurely explore it with debugger rather than decoding hex by hand, was a huge productivity boon.
So I would say - it’s better to have more than one tool in the toolbox and use the most appropriate one.
Wholeheartedly agree. There’s often good performance or security reasons why it’s hard to get a debugger running in prod, but it’s still worth figuring out how to do it IMO.
Your experience sounds more sophisticated than mine, but the one time I was able to get even basic debugger support into a production Ruby app, it made fixing certain classes of bug absolutely trivial compared to what it would have been.
The main challenge was getting this considered as a requirement up front rather than after the fact.
In the adult would model there is absolutely no contradiction about the joke you mention - it’s just a bit of cute nonsense.
But in a child’s world this joke might be capturing the apparent contradiction - the sky is “in the tree”, so it must have climbed it, to be there (as they would have to do), yet they also know that the sun is already in the sky, so it had absolutely no reason to do that. Also, “because it’s already there” - which is a tricky idea in itself.
We take planetary systems and algebra and other things we can’t really perceive as granted, but a child model of the world is made of concrete objects that mostly need a surface to be on, so the sun is a bit of a conundrum in itself! (Speaking of my own experience remembering a shift from arithmetics to algebra when I was ~8).
If not too much of a personal question - I would love to hear what your child would answer to a question why she finds that joke funny. And whether she agrees with my explanation why it must be funny :-)
reply