Hacker News Reader

Comment by api | Hacker News Reader

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.

View on HN

It'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.

> 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.

At 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

Does 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.

It 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.

It doesn't seem to matter in practice. Current generation Intel CPUs and the Apple M2 have very similar performance at the same power levels.

How 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.

You 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.

Mind 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.

Intel introduced the "running average power limit" over ten years ago. https://lkml.indiana.edu/hypermail/linux/kernel/1304.0/01322...

Rapl 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.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.

Apple’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-div..., which benchmarks chips at different power limits for an example.

Yes I agree with you. That doesn't mean this is easy to achieve. With the exception of AMD chips it's unfortunately very hard to simply "benchmark with a fixed power budget".

Your model of RAPL's abilities is too limited. "PL1/PL2" is a thing that youtube reviewers have figured out, but it is a part of a larger picture. It does not make sense to discuss them without also discussing the time parameters. RAPL is able to hard-cap the (estimated) peak power consumption. If it lacked this feature, operating them at warehouse scale would be impossible.

this article states different, so how is it?

How much power does it (roughly) use? Are we talking about 1% of the overall usage? 10%? 50%?

One 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.

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.

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.

I 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.

SIMD 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.

How is it exponential? It's only a multiplicative increase in decode positions.

Reply on news.ycombinator.com