It’s not the instruction decoder that wastes die space. In fact, it’s less than 5% of the die (on Skylake).[0]

[0]: https://pbs.twimg.com/media/EXFJLebXkAYkXTr?format=jpg&name=...

In case that link dies, it’s from [1] which is linked from [2]

[1]: https://mobile.twitter.com/GPUsAreMagic/status/1256866465577...

[2]: https://travisdowns.github.io/blog/2020/05/26/kreg2.html

> it’s less than 5% of the die

It would be equally fair to say that the same die uses less than 5% of it's space for the integer ALUs. It could also be said that the decode unit is so complex that it takes as much die space as all the integer ports put together.

SRAM may use most of the die, but it isn't using huge amounts of power most of the time as it's static. Those big SIMD units are also powered off when not used (no doubt it's the same with the other ALUs).

In contrast, the entire 5% of the die that makes up the decoder never power gates and is always running flat out. By size it's the same as leaving all your integer cores running full-out all the time.

The bigger issue seems to be that neither AMD nor Intel have been able to make those units much wider over the years which puts a hard limit on total throughput (they've hinted that the power cost on widening the decoder is very big which would mean loads of power used for diminishing returns).

It isn't so much the decoder space, but the decoder complexity that is the disadvantage of x86 chips. The problem is that the instructions have varying lengths. Only when it has decoded an instruction, the chip knows where the next instruction starts. ARM-instructions are all the same length, so the instructions can be decoded in parallel without "knowing" the previous instruction. That lets Apple go much wider (8 instead of 4) with the instruction decoders.

The x86 space for decoding is tiny. The inefficiencies have to come from elsewhere and at least partially from the node difference. An architecturally big one is that x86 only implements SeqCst for atomics whereas looser memory models can allow multi-process programs to be written more efficiently (which they have been already for mobile).

In other words I think the problem has to do with the semantics of x86 more than the syntax of decoding x86.

This was explored in detail in another thread, it seems most of the gains are from looser memory ordering.

I think that Apple "just" [1] picked a very happy place in the parameter space: lower clock means that main memory (which is already lower latency than usual) is "nearer" to the cpu plus a larger L1 with a shorter latency (3 cycles). These (plus probably a larger amount of sustainable outstanding misses) imply that the cpu stalls less which means that they can sustain a larger ILP [2]. A better branch predictor (which is rumored to be best in class, although I haven't seen any in depth analysis) means that they can usefully have a larger reorder buffer and extract even more ILP and memory level parallelism. Finally the large width can take advantage of the extracted parallelism.

The weaker memory model should help extracting additional memory level parallelism, but I doubt that ordering has large impact. M1 is quite good even when running in TSO mode.

[1] of course they need to be commended for this, they went against the usual wisdom, probably because their CPU was designed to be low power first then high performance, not the other way around.

[2] typically the average ILP for normal applications is 1.5 instructions per cycle, but the variance is high, so if you reduce the amount of cycles the cpu is stalled, the ILP can go up fast.

I agree with the rest, but memory latency is actually pretty poor on the M1:

https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste...

You’re right. Like I said, atomics are one space. Another as you point out is that the memory architecture is pretty unique at providing high throughout and lower latency than traditional x86 architectures. I suspect Intel and AMD will adjust their roadmaps accordingly as a result of this new competition.

Where does the low-latency claim come from? Benchmarks do not validate it, giving main memory latency of around 100 ns.

Apparently you are right, but because of the lower clock, main memory is still closer in cycles. It would also be interesting to know the amount of outstanding main memory references.

By the way, does someone knows where RISC-V stands regarding this ?

Yes I agree, it's more the semantics and the legacy of x86 (page sizes, MMU, memory models - even though Rosetta still runs faster than x86) than simply decoding.