Kenneth Jonsson (kj.delete@this.localhost.org) on August 17, 2012 2:41 am wrote:
> Exophase (exophase.delete@this.gmail.com) on August 16, 2012 2:52 pm wrote:

> So to spin the question a bit: what are the downsides of a large number of GPRs? It has to be fairly big
> trade-offs to be made somewhere as very few architectures seem to move beyond 32 GPRs and AMD did for some
> reason settle at 16 GPRs when they designed x86_64. Not a perfect comparison, but the performance difference
> between IA32 and x86_64 is very small so IA32 cannot be held back too much by its lack of GPRs.
>
> One point of reference to compare IA32 vs x86_64 is . Looking at the single
> core results for C and Java show that some things are faster and some things are
> slower on IA32, but the results are with very few exceptions VERY similar.
>
> Sorry for a long post, interesting topic i.m.h.o :)

Let's answer slightly differently.
If you have a modern type of CPU (OoO, superscalar, prediction, all that good stuff) then there is a distinction between the number of PHYSICAL registers and the number of ARCHITECTED (ie expressible in assembly language) registers. The number of physical registers is going to be determined by how aggressively OoO you want your CPU to be, and it is the number of physical registers that determines power, area, cycle times and so on.

Given this, the number of architected registers is essentially free. Going from 16 to 32 costs you an extra bit in each register specification (so 3 bits in most instructions) and that's it. If there is any advantage to increasing the number of architected registers, you might as well do so.

A second way to think about this is in terms of this as a "power" feature, like vector instructions, that will be used by people who know what they are doing, and not otherwise. For example: people who know what they are doing, on entry to a function, IMMEDIATELY load into a local (ie register) variable all globals that will be accessed, along with everything that will be used through a pointer. They do all their calculation in the local variables, then store everything on exit from the function. This style of coding requires a lot more registers to work with, but is also faster. (It's faster because it gets load latency off the critical path, and because it doesn't waste cycles doing things the compiler thinks might be necessary --- writing back globals, writing back instance variables --- but which you know are not, every time they are changed.)

Why isn't the code you profiled showing this sort of thing? The cruel answer would be that there are just not that many people in the world who know what they are doing. A second alternative, which might be partially true, is that the bulk of programmers, and the bulk of code written, grew up with IA-32, not even x64, where this type of programming is not much of a win because of the paucity of registers. Ideally this will change, but we all know that it takes a generation or more for certain habits to die.

Which gets back to my point. Plough-the-fields code will tend not to use half those registers, just like it doesn't use multi-threading or NEON. But performance critical code WILL use these features.