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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]