Re: Intel Core2Duo (T7400)
On Mon, Nov 12, 2007 at 02:46:00PM +0100, Gabor Gombas wrote:
> Taking the same code, going from 32-bit to 64-bit will cause a slowdown,
> period. The only way to overcome that is if you can write better code in
> 64-bit mode than you could in 32-bit mode. There are apps that indeed
> benefit from directly accessing more than 2G of address space and
> therefore can use simpler algorithms in 64-bit mode, but they are rare
> (at least on desktop).
>
> AMD knew all this and they also knew they have to counter-balance the
> slowdown if they ever wanted 64-bit to became the norm, so they did a
> smart trick and doubled the register set size in 64-bit mode. Since i386
> is a very register-starved architecture, that move indeed helped a lot
> by making it much easier for compilers to generate better code. So it's
> not only "in 64-bit mode you can keep more variables in registers" but
> also "it is easier to write good compilers for 64-bit mode".
They also deprecated MMX and x87 (hence reducing the old crap to carry
around on centext switches), and switched to sse match (which is much
faster and not stack based), and add some new instructions that can help
code in general. That almost certainly is much more important than the
register count. As far back as the Pentium Pro the pipeline's out of
order execution had a large register rename file which allowed it to do
speculative execution. It also allowed skipping stack accesses to
memory by simply renaming the old register into an unused spot in the
register file boing by the assumption that stuff put on the stack is
often needed again soon, so rather than putting it in memory, just keep
it in an unused virtual register. As a result the Pentium Pro and most
newer x86 processors actually already perform as if they had more
registers than the architecture does in most cases. I am not saying
adding registers wasn't a good idea, but I think people are highly over
estimating their significance. I guess a simple way to test is to
convince the compiler that the 64bit mode has the same number of
registers as 32bit mode and then compiling software that way and
comparing the result in 32 and 64bit mode when both have the same
register count. Shouldn't be too hard to do for someone that
understands gcc's code (which is not me).
> AFAIK Sparc (and basycally any other 64-bit capable processor) offers
> the same number of registers in both 32-bit and 64-bit mode, so there is
> nothing that could balance the slowdown caused by going 64-bit. And even
> if they wanted to use the same trick as AMD it would not help as Sparc
> already has enough registers - adding more would give a much much
> smaller performance gain than it did for x86_64.
I don't think the sparc added any really useful new instructions in
64bit mode. I believe it mainly just added 64bit versions of the
instructions where needed.
> Hehe, they could introduce a new 32-bit mode that has the same number of
> registers as the 64-bit mode has. OTOH marketing people would have a
> really tough time to push down such a change on consumers' throats...
Given the amount of ram in your average desktop is getting close to
requiring a 64bit OS, there is really no point designing anything new
with 32bit operation in mind. People have to switch to 64bit OSs if
they want to be able to use more ram within the next year or so.
But then again who knows. Perhaps 2GB of ram really is all anyone will
ever need. :)
--
Len Sorensen
Reply to: