1
$\begingroup$

In a Talk by Herb Sutter C++ and Beyond 2012: Herb Sutter - atomic Weapons 1 of 2 at 46:30 the point is made that only around 15% of the physical space (or the transistors) on a CPU do actual processing while the rest is basically just caches.

Further it is mentioned that of those 15%, only around 1% account for actual processing while the rest contains the logic for e.g. out of order execution, branch prediction, pipelining etc.

This is the slide shown: enter image description here

In the bottom right corner the source is shown to be from 2004 (the talk itself is from 2012).

Now my question is:

Is this statement true for modern processors as well or did the ratio change significantly in either direction? And are there any more sources that show this (either for old or for new CPUs)? When I tried to find more information I mostly found articles about cache sizes and how it matters or not matters but that is not what I am interested in.

$\endgroup$
2
  • $\begingroup$ (I think the question somewhat interesting - and an EE topic rather than CS.) $\endgroup$
    – greybeard
    Aug 4, 2022 at 7:59
  • $\begingroup$ I have no idea of the current ratio. Anyway, latest PC processors host vectorized ALUs, i.e. replicated 8 times as regards doubles and 16 times as regards floats (and more times for integers of various length). $\endgroup$
    – user16034
    Aug 4, 2022 at 10:44

1 Answer 1

3
$\begingroup$

I don't have any numbers for you, but that's partly because I don't know what Herb Sutter meant by "actual processing". What I think he meant is, essentially, ALUs. So you have to consider what you're comparing with.

This is a die shot of the Intel 8086, a top-of-the-line CPU from 1978.

Intel 8086 annotated die shot

What I want you to notice about this is that about 2/3 of the die is control logic, and only about 1/3 (over on the left) is the data path, and about half of that is the register file. There is a lot of die space on the right-hand side that isn't occupied by wires, transistors, and pads, so this may be a little tricky to estimate, but it seems to me that only about 10-15% of the die space seems to be used for "actual processing", if by that you mean ALUs.

So that 1% figure is 10% of 10%. When you put it that way, it doesn't seem like such a small number, at least to me.

Alternatively, let's say you do count the register file as "actual processing". Computation doesn't really "happen" inside it (not in a modern CPU, anyway), but it's pretty important; if you got rid of cache, the CPU might go much slower, but if you got rid of the register file, it wouldn't work at all.

Then consider that modern register files are multi-ported for superscalar execution, and expanded for register renaming, and this all consumes die area. How much of that is it fair to assign to "actual computation"?

The Itanium may be a bit of a special case. Just consider its user-visible register set, which is quite something:

  • 128 64-bit general-purpose registers. (Or possibly 127; register 0 was hardwired to the value zero as with MIPS.)
  • 128 82-bit floating point registers. (Again, two are hardwired to constants.)
  • 128 64-bit special purpose "application registers".
  • 8 64-bit registers just used for the targets of indirect branches.
  • 64 1-bit predicate registers.
  • A whole bunch of other stuff that you may not think of as "registers" (e.g. performance monitoring counters), but is still part of the "stored state" when you context switch.

The Itanium also has an unusual approach to register spilling. When you have so many registers, you almost never need to spill registers except when performing function calls. But the Itanium avoids that too by managing general and floating-point registers as a stack (similar to SPARC), and spilling those "stack frames" implicitly behind the scenes, automatically during spare memory cycles.

Is this "actual processing"? Arguably not, but it's not just a performance issue, it is part of the CPU's user-visible semantics.

The Itanium is unusual in how much of the CPU implementation is exposed to the programmer. Other CPUs go the opposite route: a lot of the non-"actual processing" circuitry there is to hide the caches and the speculative execution. Well, up until you get a Spectre-like vulnerability that exposes the detail by accident...

A few things have changed since 2004. Increasing transistor density influences the design of functional units, sometimes in strange ways.

Consider an integer adder. One of the things we learn early on is how to manage ripple carry as the width of an adder gets larger, through look-ahead. Modern thinking is to use a fast single-cycle circuit which works on 95% of addition problems, and then use a second cycle to "repair" the answer if it turned out to have a difficult carry pattern. You can think of this as yet another form of speculative execution, so it's getting much more difficult to see where that stops and "actual processing" begins.

Another thing that's changed is the rise of SIMD. Wide vector units allow CPU designers to add more arithmetic and logic for the essentially the same amount of instruction decoding overhead; one add instruction might trigger 4-8 parallel additions. But it does mean that some busses also need to be wider.

Finally, many CPUs have ubiquitous integrated GPUs, which complicate the "processing vs overhead" calculation further.

One last comment is that you have to remember is that people have to design and manufacture these CPUs, and CPU design is also influenced by what we can physically build. When you have 6 billion transistors to place, it's inevitable that they are designed from units that can be designed once and then replicated a lot, whether that's putting multiple cores on a die or putting in large arrays of cache memory.

The fabrication process is not perfect, either; a lot of CPUs are thrown away because they failed testing, and others are packaged and sold as lower-grade chips (e.g. lower speed, fewer cores) if they only partially failed. Some kinds of circuit are easier to test than others, and at least some of the die space is used by test infrastructure which is never used outside the factory.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.