Andy MacKay wrote:
On Thu, Apr 10, 2003 at 12:43:38PM +0100, Colin Watson wrote:
On Thu, Apr 10, 2003 at 12:39:25PM +0200, Cyrille Chepelov wrote:
Le Thu, Apr 10, 2003, ? 10:40:47AM +0100, Hamish Marson a ?crit:
I'm not sure how your logic works out that a 64 bit reg is going to
be faster than a 32bit one. Or do you mean simply you're expecting a
speedu because there are MORE 64 bit registers tahn 32 bit
registers?
Reg pressure is pretty bad on x86; and int is still 32 bit on x86-64
(IIRC, long is 64 bit and of course any T* ). So yes, anything which
plays with pointers will be larger on x86-64, but it's not an
automatic doubling in size of everything. And mapping libraries twice
also eats a good deal of memory. OTOH, 16 general-purpose 8,16,32 or
64-bit registers (not even counting a large SSE2 register file as
well) should help gcc feel more at home (especially with less code
dedicated to handling register<->memory swap-outs)
I don't have numbers to back either choice, but it looks to me that a
mixed userland with everything duplicated should be a last resort. And
I'm sure some people have numbers out these.
Based on the numbers I've seen, the factors mentioned seem to balance
each other out fairly well. I'm not (yet) allowed to talk about the
details though ...
No need to be secretive. :) In Fred Weber's MPF presentation last year
he put up some specific numbers about how code generation was affected
by going to 64-bit mode. As I recall he said that the average
instruction length increased slightly and static data size increased
(larger pointers), but both the static and dynamic instruction counts
went down because of the decrease in register spilling, and that
generally offset the bloating effect of having larger pointers.
I think the general consensus on the has been that on x86-64, compiling
for 64-bit mode is seldom a performance loss and often a performance
win. This is contrary to other mixed 32/64-bit architectures, usually
because in those cases the 32-bit arch that the 64-bit arch was based on
wasn't as archtecturally hamstrung in the first place as x86 is.
Does what I've said jive with what you're seeing, in a very high-level
sense? I don't want to get you in trouble with the NDA police or
anything. :)
Ah right. Light dawneth. Yes, you make excellent sense. Basically ia32
is so hacked about & wacky (In order to be backwardly compatible) as to
be very slow, yet ia64 is a new instruction set with none of the baggage
that it had to carry around. Thus you can optimise ia64 architecture
better than ia32.
Compared to something like PowerPC (Sparc maybe? Although I don't think
Sparc was concieved as a 64 bit instruction set was it? I could be wrong
there though) where you start with a 64-bit definition and then cut it
back to 32-bit & so gain some optimisations which make 32-bit PowerPC
faster than 64-bit PowerPC (Except where you genuinely need 64bit of
course).
--
I don't suffer from Insanity... | Linux User #16396
I enjoy every minute of it... |
|
http://www.travellingkiwi.com/ |
