5 ms·
Decoder complexity matters. ARM with its single instruction width allows arbitrarily parallel decoders with only linear growth in transistor count. X86 with its
by api 3y ago
Decoder complexity matters. ARM with its single instruction width allows arbitrarily parallel decoders with only linear growth in transistor count. X86 with its many widths and formats requires decoders that grow exponentially in complexity with parallelism, consuming more silicon and power to achieve higher levels of instruction level parallelism. It requires a degree of brute force with many possible size branches being explored at once among other expensive tricks.
This is one of the major areas where the instruction sets are not equal. ARM has a distinct efficiency advantage.
- jeffbee 3y agoDoes anyone actually care about this? The x86 decoders are not large on modern implementations, and putting more transistors on dice is a well-solved problem.
- api 3y agoIt uses more power. The decoder is like another ALU that is always screaming at 100%. It means you can easily keep up with ARM in speed but not power efficiency.
- jeffbee 3y agoIt doesn't seem to matter in practice. Current generation Intel CPUs and the Apple M2 have very similar performance at the same power levels.
- rowanG077 3y agoHow did you arrive at that conclusion? Comparing the M2 Max vs 13650HX it's very obvious the M2 Max uses a LOT less power. It's not even close, it's less then HALF the power. The M2 max has a little worse performance. But it manages to beat the Intel in some benchmarks.
- jeffbee 3y agoYou don't have to let the Intel chips scale up the power like that. You can lock them to whatever power level suits you. An i7-1370P configured at 20W has broadly similar performance to an M2.
- rowanG077 3y agoMind linking me some power measurements at same wattage? I didn't even know you could set a power target on Intel or Appl Mx. Well you can disable turbo boost on Intel but even then intel blows over their own marketed TDP by a lot.
- jeffbee 3y agoIntel introduced the "running average power limit" over ten years ago. https://lkml.indiana.edu/hypermail/linux/kernel/1304.0/01322.html https://lkml.indiana.edu/hypermail/linux/kernel/1304.0/01322...
- rowanG077 3y agoRapl doesn't allow setting a limit which is always obeyed. You can set PL1 and PL2 limits. But intel CPUs will gladly go over those limits in the short term. For example when running a benchmark. That's why I asked for specific benchmarks which include power measurements. For example: https://www.notebookcheck.net/i7-1360P-vs-M2_14731_14521.247596.0.html https://www.notebookcheck.net/i7-1360P-vs-M2_14731_14521.247... this shows the M2 has a little worse performance compared to the 1360P. But the 1360P requires 2.5x the power to achieve that.
- Panzer04 3y agoApple’s chips are on better process nodes, which confuses the issue. That being said, you really have to test chips at the same power level to get an idea of performance per watt in a comparison. You can easily double CPU power for only a few hundred MHz or 10-20% extra performance. See https://www.pcworld.com/article/1359352/cool-down-a-deep-dive-into-13900k-power-use-and-efficiency.html https://www.pcworld.com/article/1359352/cool-down-a-deep-div..., which benchmarks chips at different power limits for an example.
- arp242 3y agoHow much power does it (roughly) use? Are we talking about 1% of the overall usage? 10%? 50%?
- tester756 3y agothis article states different, so how is it?
- deleted 3y ago[deleted]
- mafribe 3y agoOne could argue that one of the reasons why SIMD instructions, and indeed GPUs, are popular, is because they amortise the (transistor and power) cost of decoding over more compute units, in the case of GPUs over many more. There are also other considerations, like rolling back state in OOO machines, or precise exceptions. All this becomes more complex with an x86-style instruction set.
- userbinator 3y agoThere are also other considerations, like rolling back state in OOO machines, or precise exceptions. All this becomes more complex with an x86-style instruction set. It's not really more complex, because those are backend concerns and work on the uop level, after the instructions have already been decoded into uops.
- ben-schaaf 3y agoI was under the impression SIMD is due to clock speed not scaling. Instruction parallelism is hard, so there's a lot to gain from just making instructions wider.
- mafribe 3y agoSIMD is orthogonal to clock-speed. There is indeed a lot to gain from having a single instruction trigger more complex behaviour, for example better instruction density, less instruction decoding needed, but all of this is independent of clock frequency. I think, but am not sure, that the Thinking Machines' CM-2 from 1988 was a 4096 or 8192 wide SIMD machine. Surely, at the time, clockspeeds where low.
- userbinator 3y agoHow is it exponential? It's only a multiplicative increase in decode positions.
- thechao 3y agoIt's not exponential; it's not even quadratic (it is superlinear), if you put any thought into the design. I worked on an x86 part with 15 decoders/fetch unit. The area was annoying, but unimportant. (We didn't commit 15 ops/cycle; just pc-boundary determination.) I've also worked on ARM/custom GPU ISAs. The limiting rate is the total complexity of the ISA, not the encoding density. In fact, from an I$ point-of-view, the tighter x86 encodings are a pretty good win — at least a few % on very long fetch sequences.
- sweetjuly 3y ago> In fact, from an I$ point-of-view, the tighter x86 encodings are a pretty good win — at least a few % on very long fetch sequences. This is still what baffles me about RISC-V's G profile not requiring the compressed ISA. The performance benefits are quite dramatic for the (comparatively) limited complexity it adds considering G already includes atomics and floating point. I think Linux is eventually going to force the issue since it's 64-bit ABI is GC.
- tux3 3y agoAt this point the G subset is just a historical notation shorthand, not really a target. The new thing is RISC-V Architecture Profiles like RVA23, which comes with the base C extension plus extra compressed instructions specifically intended to reduce code size (Zcb), bitmanip instructions, the V vector extension now being mandatory, etc etc. This is what big application cores are expected to target in the future, so if successful you could expect Linux distros to start taking advantage of those at some point