LLM-based coding is enabling so much! The crazy weekend project now can have compilation to native code and web assembly, allow server-side or client-side rendering, manage multiple types of persistence, include adaptive compression, and do all of this without breaking a sweat.
I've found Claude Code with Opus 4.5+ to be excellent at generating test cases that exercise the different features, and even push into the edge cases. You sometimes need to nudge it into generating more convoluted cases when necessary, but then it is just nudging. I now routinely generate more LOCs of test cases than actual core code, while I used to only write very limited test cases just for the most complex areas amenable to automated testing.
I've been successful at using Claude Code this way:
1. get it to generate code for complex data structures in a separate library project
2. use the code inside a complex existing project (no LLM here)
3. then find a bug in the project, with some fuzzy clues as to causes
4. tell CC about the bug and ask it to generate intensive test cases in the direction of the fuzzy clues
5. get the test cases to reproduce the bug and then CC to fix it by itself
6. take the new code back to the full project and see the issue fixed
All this using C++. I've been a pretty intensive developer for ~35 years. I've done this kind of thing by hand a million times, not any more. We really live in the future now.
Oops, sorry about carelessly throwing the "cringe" label at that. Thanks for the transcript which allowed me to enjoy the content, which I did find very interesting.
I haven't watched the video so I am not sure how he actually talks, but what read cringe to me was things like the following paragraph:
"Stephen Robinson: Yeah. So let’s, let’s break it down into address generation versus execution. So, when you have three load execution ports, you need three load address generators. And so that’s there. On the store side, we have four store address generation units. But we only sustain two stores into the data cache."
Which reads weird. "let's" repeated twice, probably a stutter, could be transcribed just once. The "So" or "And so" the interviewee uses all the time at the start of sentences can also be removed for clearer and easier reading most of the time, without loss of meaning. Some sentences can almost be removed completely as they provide no actual information. The previous paragraph could be transcribed like this:
"Stephen Robinson: Let’s break it down into address generation versus execution. When you have three load execution ports, you need three load address generators. That’s there. On the store side, we have four store address generation units. But we only sustain two stores into the data cache."
I hesitate to remove "That's there." so I left it. But everything else I removed, it makes it clearer, and I think I'm not being unfaithful to the original. Removing the duplicate "let's" is a given as it's normal to stutter when speaking, but you don't really want to transcribe that unless the goal is to transcribe the talking imperfections we all have. And all the other things I removed, "Yeah", "So", "And so", are basically the same type of thing.
I thought this was automated because it had so many of the meaningless go-to words and hesitations from the original. Now that you mention it, automated transcription would probably never have produced something this good. And otherwise we are talking about stylistic preference here, always subjective -- although I'd definitely prefer the style of transcription suggest here.
Thanks again. I read chips and cheese with interest, quite often, and enjoy it quite a lot. Keep up the good work. And sorry for the careless put-down.
He is no Jim Keller, and the mostly[1] automated transcript makes it read cringe, but it is not at all devoid of content.
Some examples of very interesting, non-obvious content:
* Even if store ports are kept fixed (2 in his example), adding store address generators (up to 4 in his example) actually improves performance, because it frees up load port dependencies.
* Within the same core, they use two different styles of load/address address contention mechanisms which he describes as two tables, one with explicit "allows" and the other one with explicit "denies" -- which of course end up converging (I understand it refers to two different encodings which vary in what is stored).
* Between cores, they have completely separate teams which reach different designs for things like this.
* It was interesting to me to discover how isolated the different core design teams work (which makes sense)
* It was interesting to me to picture the load/store address contention subsystem, which must be quite complex and needs to be really fast.
And I stop listing, re different types of workloads, gaming workloads being similar to DB workloads, and even more similar between them than to SPEC benchmarks and so on.
Just go read the interview if you're interested in CPU design!
[1] mostly automated: at least the dialog name labels seem to be hand-edited, as one of them has a typo
The white keys form a sequence of notes (frequencies) that is known as the diatonic scale. It's the foundation underlying all popular western music. It is not random or arbitrary, it has some nice dual mathematical and musical properties: intervals between the notes in the scale have special frequency ratios that sound pleasing to the ear (read Helmholtz's "On the sensations of tone" for a fascinating physically-based take on why it is like that -- he is known as "the father of acoustics", and that book contains the distillation of 8 years of deep, smart research way before we had the means or understanding we hav today). A ton, if not most, of popular music can be played using only the white keys.
There used to be keyboards with other different arrangements, which were actually extremely cumbersome and actually didn't allow very rich and interesting musical excursions like modulations (look up "microtonal keyboards"). Today's standard keyboard and tuning is a compromise between those fundamentally mathematical and perceptual acoustic relations (the tonic, the fourth, the fifth, the sixth, the major and minor third, the "sensible" or subtonic...) and the ability to perform those trans-tonality excursions. A fully regular keyboard like you propose would lend itself more easily to those excursions, at the cost of being less apt at the foundational diatonic model and most popular music.
Interestingly also, the notes used by modern keyboards and all modern instruments, and to which we are all so accustomed that we thing it "just is", is an imperfect compromise that needed a lot of selling back in the day, much of which was done by Bach (the compromise scale is called the "tempered scale", and Bach authored the arch-famous "Well-tempered clavier" pieces to show it off -- impossible to perform on keyboards with other tunings).
And of course, there is a tradition factor. English isn't written like this because it's optimizing for any easily describable or measurable optimization metric, more like it minimized a socio-perceptual function covering many centuries of UX.
Finally, if you want an instrument where all keys are equal, you can always move to a fretboard based one like the guitar. Funnily, it has a one-semitone-short jump between strings 3 and 2 that will throw off the desire of full regularity... again due to diatonic leanings. A bass guitar is fully regular, even when they add a 5th and 6th string, so that may fulfill your wish of a fully regular instrument... and it sounds awesome! Just can't do the same things as a piano or a guitar.
Such a needlessly negative article. PCIe 5.0 is early, peripherals are scarce-to-non-existant, and existing rigs are not infinitely flexible. Otherwise, it all looks pretty good to me. Even buying one of those may prove worthwhile as new graphics cards and SSDs are released.
I'm so grateful to him, his early work was a massive influence for me as a kid. I lent one of Dewdney's books to a neighbor friend's dad, an architect, and he gave me my first paid gig as a programmer. Can't overstate the influence in my career.
Also, I distinctly remember his column showing how to generate text based on statistics learned from an existing corpus. It has come to mind more than once in this last period of LLM magic -- the essence was already there.
Nitro "virtual NVME" device are mostly (only?) for EBS -- remote network storage, transparently managed, using a separate network backbone, and presented to the host as a regular local NVME device. SSD drives in instances such as i4i, etc. are physically attached in a different way -- but physically, unlike EBS, they are ephemeral and the content becomes unavaiable as you stop the instance, and when you restart, you get a new "blank slate". Their performance is 1 order of magnitude faster than standard-level EBS, and the cost structure is completely different (and many orders of magnitude more affordable than EBS volumes configured to have comparable I/O performance).
Beautiful, I love it, congratulations! I started my programming journey with Basic on a ZX Spectrum +, then Z80 assembly language, then 8086 and the rest from there... 40 years of programming and my appreciation for my original platform is still there. Thank you for the tribute.
I've often heard about the Linear B mystery and its final decipherment, but never in so much detail. That was fun. Now, when will there be something similar for the Iberian language...
Probably because changing the software to use a different read pattern is doable in a few weeks/months on your existing systems, and changing anything in the flash controller is a wicked project probably only available to hardware manufacturers, and which will take months to years given the immensely slower hardware iteration cycles (even if it's "just" firmware changes).
Oh so it's a GCC-specific thing... that explains it. In any case, congratulations on the lisp! It's beautiful code. I wish my current codebase was that beautiful. I mean, it's a lot of us contributing to it so the beauty is a kind of "meeting of the minds" situation... but still :)
PS: My current project implements a lisp... rendered as JSON. Some other angle on beauty...
Beautiful. Also, after 30+ years of writing C and C++, I learned one thing by casually browsing the source code: you can use a preprocessor macro in an #include statement. Thanks.
I have written and been using that same smart pointer type for years, under the pretty horrible name of holder_cloner_t<> (at least it's clear). It is indeed the right solution to a very common and important type of problem. Looking forward to something like this in the standard library one of these decades.