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.
Assuming a pure x86-64 (no 32 bit support) can be bootstrapped with relative
ease, I guess it would be very interesting to see a couple benchmark (speed
and memory) numbers against running the exact same package selection but
from the i386 archive. It looks to me that the /lib-vs-/lib64 scheme
should have enough room to let people make the right tradeoff between
running full 32-bit (but allegedly smaller in data sizes), full 64-bit (but
allegedly faster in code in some situations, and probably slightly larger in
data size) or a mixture (obviously mapping common libraries twice), using
their own workloads.
-- Cyrille
--
