Comment by smoldesu | Hacker News Reader

Comment by smoldesu | Hacker News Reader

x86 isn't dead, in the same way the ARM wasn't dead when the Raspberry Pi existed. Until we see 5nm x86 chips, it's going to be awfully hard to evaluate just how large of a lead ARM has on the desktop. And that's before we get to the real sticking points; legacy software. x86 is really, really good at maintaining backwards compatibility, and even has a number of objective leads over ARM in it's current iteration (for example, native SIMD beats the pants off NEON any day of the week). For ARM to claim supremacy, it's going to need to run the same software that x86 does, without overhead. Simply due to the difference in architecture, that's going to be astronomically difficult.

A more likely theory is that we've now entered the big.LITTLE era. Intel has already begun to pivot their desktop line to the big.LITTLE design, and while AMD's next line won't follow suit, they've discussed bringing the architecture to the CPUs after that. x86 has still got quite a bit of gas left in the tank, and now that RISC-V is getting taped out, a lot of people are starting to realize that a more modular approach to RISC CPUs is probably smarter than how ARM exists in it's current iterations. Plus, ARM is still proprietary (arguably moreso than x86), whereas RISC-V is fully open for anyone to use and manufacture. Simply from a technical side, I think RISC-V is going to eat ARM's lunch within the decade, and I also think traditional architectures like x86 aren't going away any time soon. Time will tell.

I think this is closer to the truth. X86 isn't going anywhere because it's been pretty adaptable over the last 43 years. The newest adaption is the big.little design. It will be interesting to see AMD's answer to it. Unless something majorly disrupts the Win/Linux on x86 space, it's going to be around for the foreseeable future.

Also, we've heard these arguments before with Intel i960, IBM PowerPC, DEC Alpha, and Sun SPARC. At the end of it, x86 is still around.

Genuinely curious if any of the prev alternatives were more performant as well as power efficient?

PowerPC was more performant but limited to Apple (echoes of the current M1). The best place I know of to read about that era is Tom Hafhill's Byte Archive. Which has many articles from the 90s about x86, PowerPC and DEC Alpha[0]. Intel (x86) has always been very difficult to compete with because historically they've been able to integrate new technologies into the ISA quickly.

DEC Alpha was more performant than Pentiums, but they caught up eventually. Pentiums were far, far cheaper, however.

Power efficiency wasn't really a thing back then. The original Pentium was an 8 watt part, the common DEC Alpha (21164 in '95) was a 30-50w part.

[0] https://www.halfhill.com/bytelink.html

> PowerPC was more performant but limited to Apple (echoes of the current M1).

IBM shipped a lot of PowerPC machines also. I think they still have some current machines on that architecture.

> Power efficiency wasn't really a thing back then.

If I remember right, that was what caused Apple to switch to Intel. IBM just couldn't get the heat and power consumption on the G5 down to a level that would make it feasible for laptops.

IBM still does, it's called the PowerISA now instead of PowerPC (I guess we're finally in a post-PC world after all).

And yes, I think that's right about not being able to get the heat down for laptop parts. That's still over a decade after the PowerPC 601 that competed with the Pentium (P54C). By 2006 it was pretty obvious that x86 had 'won'. DEC Alphas were discontinued, Sun was well into financial difficulties, and SGI (MIPS) was in serious financial trouble, and Apple was moving to Intel.

Side note: A lot of these arguments really happened over 20 years ago. This has actually been a really nice walk down memory lane.

I wonder if big.little is the first step in really hetereogenous architectures.

Once we get OSs capable of understanding "this task should be executed on cores 0-7, and these others can be on 0-15", it's a much smaller step to "this task can only be executed on cores 0-7 and will be literal gibberish on the other cores". Over time, you skew the core distribution until x86-64 is a legacy product and you install a separate accelerator that has a couple of cores on it if you still have x86 software that can't be emulated efficiently.

What worries me about ARM and RISC-V is that the diversity of SoC design that makes them great for embedded systems, makes them awful for a desktop PC where third-party software and peripherals matter. In that sense, any attempt to ask "will ARM/RISC-V replace x86/x86-64" has to be followed up with "which ARM/RISC-V".

We'd need someone that could unite the industry around some standards for an ARM/RISC-V desktop. I worry that may end up being Microsoft, because they have a unique potential gatekeeping position with their closed-source portfolio. They can say "this is the right memory map/device tree for Windows ARM/RISC-V" and actually exert leverage on manufacturers. (If a Linux/BSD product tries the same, vendors can always patch around it).

The alternative is chaos. Even in x86 land, with only two meaningful players and huge installed bases of each, we had various instruction sets that took forever to get adopted, or just withered entirely (3DNow!) because people didn't consider them part of the least common denominator.

Speaking of big.little, you've got to acknowledge that Intel's doing this right now in their i9 Alder Lake x86_64 CPUs (8 performance cores + 8 efficiency cores). So I think this isn't going to be exclusively an ARM problem...

Reply on news.ycombinator.com