A primer on x86 by Casey Muratori and The Primeagen [video]
youtube.com
youtube.com
* x86_64 traditionally only has 16 registers and destructive instructions. This is apparently also a problem for Intel, hence, they introduced APX which goes to 32 GPR and adds three-operand instructions. But who will use APX in the next 10 years outside specialized server software and gentoo users? Consider that most applications still target x86-64-v1, and runtime dispatch isn't really practical for this.
* Piling on ever larger SIMD extensions. This is not so much a burden on the implementation, but on the software landscape. The way intel and AMD traditionally seem to implement SIMD instructions, is to have execution units that can do an operation of the largest SIMD width, and use those to also execute the smaller SIMD widths. That seems reasonable, and probably is a good tradeoff given the decode complexity, but it also means that not using the latest SIMD extension wastes a lot of compute power. If decode was easier, you could've stuck with one SIMD width, and just add more execution ports, which means that older software also gets a speedup on newer generations. This is kinda what AMD did for Zen 4, where they implemented AVX512 on top of AVX2, instead of the other way around. Or how ARM implementations that only support 128-bit wide NEON can keep up with AVX2 (256-bit) and sometimes AVX512 (512-bit).
* All the legacy things may not cost much in terms of die space, because they are implemented in microcode, but I'd imagine they have significant development and verification costs.
Edit:
Another aspect regarding decode complexity is that the latest ARM cores started removing the uop cache, this would be pretty much impossible for a fast x86 implementation. I wonder how ARM decode width - uop cache and x86 decode width + uop cache scale for wider and wider cores.
There is a decent chance that the bytecode runtimes will enable this instruction set in their JIT output. This would include .NET, JVM and V8.
https://developers.redhat.com/articles/2024/01/02/exploring-...
Redhat 9 went v2 and they are pushing for v3 now...
I think the drums are beating for this to change in a lot of places. Debian will end up being the hold out and (as a Debian consumer) I dont know how I feel about this...
The target platforms are also a bit narrower.
Huh? The longest supported Debian releases are the ELTS releases, which have 10 years too - and is not an official Debian project. Five years are the LTS release.
Not sure how RHEL's 10 year life cycle is more aggressive in what it has to support.
Not really. The unused parts of the SIMD execution units are powered down.
The only problem is that Intel has not introduced instructions for switching the execution width and the attempts to detect the intentions of the executed programs can never be perfect.
Therefore whenever a program starts executing wider instructions there is a large delay until the wide execution units are powered on and during that time the speed is much lower than possible. When a program stops using wider instructions, there is an even greater delay until the execution units are partially powered off and during that time there is a waste of energy.
All these inefficiencies could have been trivially avoided if Intel had not tried to be so clever, but they would have just allowed the programmers to have control over the power consumption, because only they know in advance what their program will do in the future.
True, and that helps with frequency and power, but what I meant with "wastes a lot of compute power" is that e.g. you have an avx2 capable execution unit that can do 256/32 float adds in parallel, but only a single SSE instruction can be scheduled to it, hence you can only get 128/32 float adds via SSE on that execution unit.
I don't think his style is for me personally, but I definitely feel the world is a better place with his voice in it.
[0] https://www.youtube.com/channel/UC6biysICWOJ-C3P4Tyeggzg
Some examples: reaction to other videos rating programming languages, reading out articles (like one guy shutting down some cloud services and instantly realising half a million bucks savings for the company) while commenting out loud but adding little to nothing useful, and some neovim videos where he basically copy-pastes some code here and there and sone functionality appears (without any actual explanation about how the code he pasted actually works).
I like the guy, but i’ve realised that:
1. His content is not a good use of my time (wrt my interests and my skill level)
2. When he makes actually good content (like this one in this case) it’ll reach me anyway, somehow.
Hence I unsubscribed.
Casey has his 'nominally' priced course, which is excellent. I recommend it.
And that video would've reached his already existing audience of people who already know they're interested in that stuff. Being on Prime's stream hopefully exposes a lot of new people to both him and the topic as a whole.
https://hackaday.com/2024/03/21/why-x86-needs-to-die/
The article is, uh, well it’s bad. I’m a little hesitant to respond point-by-point to an article like this because it just sucks up so much time, and there’s just so much wrong with the article on so many levels. Here’s the response article:
https://chipsandcheese.com/2024/03/27/why-x86-doesnt-need-to...
The video appears to go into detail about things like how pipelines but it’s a long video that just doesn’t get to the point fast enough. I think the video is somewhat tearing into the article and ripping it apart, but I hear some comments in the video which I think are not that great, like at 1:01:25:
> RISC is reduced instruction set computer, just means not very many instructions
RISC is better understood not in terms of the acronym itself, but as a label for the way CPUs were designed post 1980 or so.
In this case, the one named like prime number, seems to spend extraordinary amounts of time waffling on about nothing in particular on twitch streams with a relentless torrent of energy, and then this feeds the echo chamber of their fans.
Nothing of substance is touched on more than briefly. I am not really sure what the point was of this whole article and guest appearance.
I wouldn't try to infer much about the real person from the content.
Any evidence? He was at Netflix for practically a decade, and Netflix is known for letting go underperformers very quickly.
This is not a tight, edited, informational video. It’s not even a scripted presentation. It’s two guys reading an article and reacting to it. They spend some time talking about Three-Body Problem, and Twitch streaming.
RISC is a collection of ideas about how to build chips that came about in the late 70s and early 80s. CISC is a retronym for things that didn't have those ideas. Some ideas worked out. Some ideas have failed. It's no longer a useful concept for talking about computer architecture; let's instead talk about the actual microarchitecture of the chips.
(Also, yowsers, that original article really is bad.)
It’s interesting to hear stories from the actual designers of CISC chips, because they talk about the things that they did to try and make their chips faster and more useful. “Lots of addressing modes” is one of them, and it kinda turns out the future is to have fewer addressing modes.
And the reasoning for it is kinda interesting. Like, imagine that you have a memory indirect addressing mode, and decide to throw an increment on there for good measure. That’s cool and all, but most compilers never figured out how to generate those instructions, and you can get two page faults from a single damn instruction. Kinda makes it hard to deal with exceptions correctly.
There are also a few bad ideas that came out of the natural evolution of RISC doctrines. Non-interlocked instructions and hazards, VLIW for general-purpose CPUs, a few others. I think in general, if you expose too little of the details of how your CPU works you sabotage anyone trying to write fast code, and if you expose too much of the details, you sabotage your ability to ship a new CPU that works differently.
I think if they'd had started now (/ more recently) and been much more open source-y they'd be in a much better position e.g. it's interesting enough that random autists will work on their toolchain
RISC-V started in 2010, had a prototype chip by 2013, and now has dozens of implementations in shipping products.
I suspect the Mill project "bit off more than they could chew". They not only had to develop a new chip, but a matching compiler, instruction set generator, and a bunch of other bespoke tooling.
They did however seem to imply that they didn't even have FPGA models going maybe 5 years ago at this point which did seem pretty bizarre.
Perhaps it doesn't actually matter for what they're doing, but you'd think that they (in their supposed pursuit of seed money) would have a blinking LED or something just to have something to show off...
In that sense, classic x86 is going die.
I remember when 'PC Compatible' was absolutely required to be a player in the market. Then, laptops came out and it was suddenly not a thing. Nothing a PC did could be done on a laptop (no accessory cards, new code to use laptop features etc) and the lure of portable overrode any marketing hype.
As markets grow the decisions we make, the optimal product locations, it all changes. You have to reinvent yourself to stay vital.
Michael Dell wrote about this. Every time Dell doubled in size, he had to reinvent the corporate processes. Things that were manual had to be automated, the job got too big for a single person (support, inventory etc).
And things that used to be automated, had to be made bespoke - remember the days when you could 'dial up' a custom Dell computer, every feature? They'd make just the one you wanted. All done on a website, that I imagine resulted in a ticket in front of an assembly line worker.
Then they dropped that, probably because there were no more workers on the line, that got automated too. Then you had options, but from a short list. And only the popular options survived.
I'm just surprised that hardware can persist so long. For instance x86 started in 1978! Most folks using it were not even born back then.
We could really, really use more innovation in the hardware space. For the first ten years it was all about putting mainframe features on silicon, not a lot to invent, just the die getting smaller so more fit, caches and paging and DMA and multiple busses.
Did anything happen after that? I'm not sure it did. What might have happened? Well, real security for instance. Keeping the kernel space 'secret' is a botched idea, we all know secrecy isn't security. Witness Spectre, Downfall and so on.
And why hasn't more of the kernel migrated into silicon? Waiting on a signal, communicating between processes, blocking on an interrupt, mapping memory to user space for i/o and on and on. All possible in silicon, all would avoid thousands of machine cycles and blowing process caches.
What do we get with each new generation? A little faster, a little less power. More compromising kernel bugs. Sigh.