Is x86 at the end of the road? I don’t follow closely, but I impression is it’s been getting faster and faster ever since AMD stepped up and provided some competition with Ryzen.
Where they fall down is on perf/watt, not raw performance. However there’s a lot of things that go into that difference, not just ISA, so I’m not sure if anyone has really decided if x86 is fundamentally less efficient, or just currently less efficient due to current design choices and constraints.
Raptor Lake is a pretty big jump in perf/watt. In just one generation they are claiming similar perf to Alder Lake at 250W but just 65W on Raptor Lake. AMD did a similar huge jump in efficiency last year with Ryzen 6000 for mobile
No. AMD and Intel are the oligopolistic providers for an unbelievably vast software ecosystem that practically rules all computing outside embedded (and some legacy mainframes here and there), are they going to throw away that market position just because the cleaner encoding of ARM or RISC-V would save an estimated low single-digit % of decoding power [1]?
[1]: https://www.usenix.org/system/files/conference/cooldc16/cool...
Micro-op caching enters the room.
I mean, seriously, micro-op caching has been extensively used for over 20 years, including on ARM64 designs although Apple M1 doesn't have it.
This problem does not apply to RISC-V, where with the C extension you get either 32bit or 2x 16bit. The added complexity is negligible, to the point where if a chip has any cache or rom in it, using C becomes a net benefit in area and power.
ARMv8 AArch64 made a critical mistake in adopting a fixed 32bit opcode size. A mistake we can see in practice when looking at the L1 cache size that Apple M1 needed to compensate for poor code density.
L1 is never free. It is always very costly: Its size dictates area the cache takes, the latency of this cache, the clocks the cache itself can achieve (which in turns caps the speed of the CPU), and how much power the cache draws.
As you mentioned decoder width: There's Ascalon[0], a RISC-V microarchitecture that's 8-decode (like M1), and 10-issue, by Jim Keller's team at Tenstorrent. It isn't in the market yet, but is bound to be among the first RISC-V chips targeting very high performance.
Note that, at that size (8-decode implies lots of execution units, a relatively large design), the negligible overhead of C extension is invisible. There's only gains to be had.
C extension decode overhead would only apply in the comically impractical scenario of a core that has neither L1 Cache nor any ROM in the chip. Such a specialized chip would simply not implement C. Otherwise, it is a net win.
In any case, if Intel needs to diversify, open source (RISC-V) does seem better than proprietary mortal enemy (ARM).