BREAKING: Intel, AMD, Linus and more team up to save x86

Intel and AMD are working hard to keep x86 alive against the impending threats of ARM and RISC-V. Will the x86 Ecosystem Advisory Group be enough?

SOURCES

S/O Ph4seOn3 for the awesome edit 🙏

[cx-software-hardware]

PSA: I am a hardware engineer and there is an astonishing amount of misinformation in the hardware part of this video. I know it's coming from a JS dev so no flame, just thought I'd let you know.
(P.S. microarchitecture determines power efficiency **NOT** instruction set)

[mattrulz]

Hi Theo! IDK if you dig through the YouTube comments, but I saw this and really felt like people might come away with the wrong idea. You make a few good points, but I'd like to set a few things straight about RISC/CISC/Intel/ARM. Here's two helpful of helpful bits of info, in no particular order:

- x86 implementations very rarely have ALUs that completely implement every version of the 3, 000-odd instructions, that's what microcode is all about. Under the covers, a modern Intel chip is a RISC-like system (kind of, it's complicated, asterisk-asterisk) running it's own ""emulation"" (kind of, it's complicated, triple-asterisk) of the entire complex instruction set. YES: This does make the architecture overall, in at least some measurable ways "more complicated" than ARM. Intel has really struggled on some architectures to optimize the tradeoff between "what do we build an accelerator for in silicon" vs "what do we emulate in 7 clock cycles of microcode". But they're always at least trying to innovate here. NO: x86 does not, and I believe[would need to fact-check and I do not have my textbooks handy] that even the 8086 had a few of the complex instructions that were ""emulated"" in that way. They took several clock cycles because they were stepped processes like add/carry/jump etc.

- One of the main tradeoffs that my computer design textbook lists as The Difference between CISC and RISC is NOT speed; i.e. it is NOT necessarily about fewer OVERALL clock cycles. The book lists the example that while in theory complex instructions [like multiply] COULD be implemented in one clock cycle on CISC, in practice this basically never actually are. The BIG DIFFERENCE the book (Computer Architecture and Design, I have an edition from 2016, not sure the ed number) is about CODE PAGE SIZE. In RISC, complex instructions have to be _written out in your code_, whereas in CISC some segments can be represented extremely compactly and then it becomes the processor's job to translate those individual instructions into ops during decoding. Why is this important? Cache Lines! More instructions in the pipe theoretically means higher throughput / fewer cache misses / more code resident in RAM, etc. This was EXTREMELY important back in the day when memory was an expensive commodity! That was ((at least one of)) the reason(s) that Intel made this tradeoff in the design of the 80-series. Back when it was designed, you could fit literally more code more compactly into the same memory and memory was PRECIOUS.

[citation, while not a computer architect in practice, I studied low-level hardware in college under a professor who seriously knew his shit. We used Computer Architecture and Design as a textbook, and Prof Whose Name Shall Not Be Shared Lest I Get Doxxed was a prominent member of the IEEE, a practitioner in the 70s and 80s, and pulled stunts like bringing in an actual board of hand-wound Core Memory from an ancient PDP for us to look at, he knew his shit]

I will happily go back through my class notes and textbook for actual references and a proper bibliography, if anybody cares lol

[aoi_mizma]

I know this is coming from a JS dev, but almost everything about the architectural comparison between x86, ARM and RISC-V other than just numerical facts are wrong in this video... Maybe should have done a little more research or let someone with a lot more knowlege about the field explain...

[dyto]

11:20 this is false. Intel does put dedicated video encoding chips on x86 CPUs. And they did it way before Apple even though about it.

[SpikerStudios]

Only at 03:00, but I want to add that x86 is a *licensed* architecture. Same with ARM.

However, RISC-V, is not licensed. It is open source, and zero license.

Which is why I'm personally backing it as the next major platform

[Maxjoker]

"x86 is in a rough state"
No, I'd argue that "the state" of x86 is still "the best". When it comes to high-performance desktops, workstations, servers etc. there is really only one option right now, and that is x86. Software support is also still best on x86, including things like toolchains, compiler(-optimization) support, legacy applications, etc. - It's only in certain niches that other architectures are even a thing.
Of course x86 still has it's problems, including that it is ancient, huge and has quite a bit of "cruft" - That's what I assume that x86 Ecosystem advisory board is about.
But pretending that "x86 is in a rough state", and that it desperately needs saving when it is clearly still the best and default option is misleading.

[---..]

Wow, I couldn't watch that whole thing. Sometimes I forget Theo understands hardware worse than he understands Rust. This is an interesting topic, and thanks for bringing it to my attention, but I'm not going to get my information on the subject here. I get the feeling that Theo wants to do to X86 what JSSugar wants to do to JS because complexity he doesn't understand doesn't seem justified? Really common mistake, but you can avoid it by either sticking to where you are an expert, or actually learning more about things you talk about.

[Chriva]

7:20~ Number of instructions doesn't say much. The instruction decoding takes little to no silicon space compared to everything else like cache, multiple ALUs, multiple FPUs, SIMD stuff and pipeline etc (This is PER CORE, add glue logic and multiply by number of cores).
Pretty much all IPC gains we've seen since the 90's is because of smarter pipelining/branch prediction and the number of operations it's able to do per clock cycle, not the ISA or how simple/complex it is).
One could probably argue that a bigger decoder adds a very miniscule amount of additional draw but all the other crap is the real culprit. More performance == the bigger number of ctrl+c, ctrl+v of individual components inside each core.

[bean_TM]

you got so much wrong here. go watch that prime+casey video you mentioned since its relevant. the instruction set doesnt matter since it goes down to uops anyway.

[ryanseipp]

x86_64 and arm both decode instructions into micro operations that are actually executed. So the complex instruction might actually become several loads, adds, multiplies, stores, etc. that get shoved down the execution pipeline. Very true though that x86 needs much more active silicon to do this decoding though. A core piece of the inefficiency here is that each instruction may have a different byte width which complicates the decoding logic, where I don't believe this is true for arm or risc-v. It is crazy to me that AMD and Intel CPUs still support 8, and 16 bit memory modes in 2024.

On Apple's video decoder, both intel and amd have dedicated accelerators on chip to do this work too. See Intel's QuickSync released in 2011. Similarly QuickAssist (QAT) offloads a lot of network packet processing.

[Bennigames]

That's not how instructions are handled like at all. They get broken down internally into other simpler instructions so no you don't have seperate handling for all instructions baked into the silicon

[sarjannarwan]

I’d recommend having a chat with Casey Muratori (he’s been on prime’s stream) think you could learn a lot from him, he’s deep in the x86 world.

[dnmcgoy]

When you say there’s a paraphrase of “arm is eating our lunch now”
I read an additional level:
“If we had done this up until now we would've had the anti-trust whistle blown at us”

[bedngrs]

Change the default page size from 4kb to 16kb would go a long way towards enabling x86 to have some runway for the future

[voltflake]

Some videos should not exist, this is one of them

[_tsu_]

That’s not how any modern processors work. They are basically Jit compilers for its variant of the assembly language. The actual operations are called uops which are summing, division, etc

[jaklegacy]

I guess Theo wasn't aware of integrated graphics that have existed for a decade at this point?

[DrInnappropriate]

This isn’t about saving x86. This is about intel getting their AMD patent agreements undone so they can sell the company for parts

[monstercameron]

x86 isnt a rough license. You literally cant licence it. At this point the only reason AMD has an x86 license is because they made good products during the Athlon64 days and ushered in 64Bit computing for the platform and Intel licensed their design. They then did a perpetual cross licensing deal and they've been tied together ever since. I am making this distinction because Intel blocked Nvidia from licensing x86 in the recent past which is what lead Nvidia to license transmeta tech and produced interesting ARM based architectures starting with "denver" cores. The lore is hella deep Theo.

[ShaneFagan]

Gotta hand it to the comment section, generally they have had the right reaction to a bunch of things here, no hate because I don't think your reaction is bad just the details and why this is interesting is something of note.

1. x86 and ARM both have the same problem in that they are licensed, ARM though has a single company ARM itself steering it and you were right to highlight the fractured nature of AMD and Intel but they have also added features like video encoding to their chips in the same way as ARM and that is done not through ISA improvement it is done through libraries like libva accessing those chips
2. The number of ISA instructions shouldn't really matter to you as a dev but has a lot of implications from a complexity of design standpoint. The compiler decides how to differentiate the signals between x86, RISC-V and ARM variants. Stuff like Box64 and Rosetta just do that after the fact and shouldn't be a huge issue to applications overall but does have an effect on speed. If the processor has more cores because the complexity it lower it can do more things at once, if the ISA is more complex they might not need as many instructions to complete a task. There are tradeoffs at both ends of the spectrum.
3. RISC-V isn't open source it is an open standard and can run into the same fragmentation issues as other ISAs just that you don't have to license it and can propose extensions to the foundation. Another point about standards is Cuda already is competing with an open standard OpenCL which both AMD and Intel support the ISA discussion would be more here introducing specific instructions to accelerate those workloads but there is no real hint that there is a new Cuda alternative coming down the line. Also AMD can support Cuda as long as it isn't using Nvidia libraries or code, see the Google v Oracle case on Java use in Android, you can't copyright APIs. Similar WINE on Linux also does conversion of calls.

My hot take is this is going to be a great cleanup of x86-64 from both Intel and AMD, they will push those changes to compilers after they disable those instructions and it will give a bit more longevity to the platform but I think if you asked both do they see ARM on desktop being a primary platform in the future they will probably say yes regardless of the partnership. A key point though and no one seems to mention this is who the partners are in this effort, they are all cloud providers. Cloud is still and will still be x86-64 based for at least another few decades because of how slow server compatibility moves. CISC makes a lot more sense in that domain anyway because it is less about power usage for your household or battery life on a laptop and way more about complex workloads and efficiency. So I don't see much movement in cloud at all other than a bunch of edge stuff maybe to ARM or RISC-V in the medium term.