64 bit computing (was: [Gllug] Fileserver hardware advice)

[Richard Jones]

On Mon, Mar 19, 2007 at 10:37:26PM +0000, Martin A. Brooks wrote:
> Mike Brodbelt wrote:
> >>4) Finally, how much difference will having a 64 bit CPU make when it 
> >>comes to performance?
> >
> >It'll likely make things marginally slower for the same clock. Pushing 
> >64-bit pointers around takes a bit more work. 
> 
> Now it's not often that you and I disagree, Mike.  I'm not sure we are 
> disagreeing here, but I just want to make sure.
> 
> Where does this myth about 64 bit processing being "slow" come from?
> 
> Sure, 64 bit binaries may be a tad bigger, but how does that equate to 
> being slower to execute?

It is, as ever, swings and roundabouts.

Cache argument:

64 bit binaries are larger, so given two processors with identical
cache sizes but one being 32 bit and the other being 64 bit, the
larger (64 bit) binary will suffer because it is more likely to exceed
the available cache.  There are two problems with this argument:
firstly, 32 and 64 bit processors aren't really comparable in this way
because so many other things are different about them.  And secondly,
64 bit binaries aren't full of 64 bit constants, and so are not really
that much bigger, particularly on x86 where the weird instruction set
acts as a form of "binary compression", and where in any case you
probably have instruction translation going on with trace caches etc.

Register pressure argument (x64_64):

The 32 bit i386 has extraordinary register pressure (very few useful
registers), even when compared to processors of a similar age from
other manufacturers.  This means in the average C function the i386 is
much more likely not to be able to store all local variables in
available registers, so needing to spill into slower memory more
often.  AMD showed a lot of sense when they provided 16 registers for
x86_64.  A big improvement.

"Pushing 64 bit pointers around takes a bit more work" (from GP):

I'm not even sure what this means.  All processors (even "32 bit"
ones) have wide data paths to and from memory - at least 64 or 128
bits wide, and often effectively much wider if they are able to do
burst mode transfers - so there is no real difference.  Perhaps the GP
means inside the processor, to and from registers and ALUs?  That's
also nonsense because the whole point of a processor with 64 bit
registers is that it can transfer the whole register in the same
number of cycles as its 32 bit bretheren.

Larger address space argument:

Current 32 bit processors have to go through all sorts of hoops to
comfortably fit kernel and userspace processes in memory.  (For
example, try running a 32 bit machine with >= 4 GB of physical RAM,
lots of 32 bit DMA devices, loads of kernel memory allocations and
some large processes.)  The huge address spaces on 64 bit processors
(not actually 64 bits, but more likely 40-48 bits) make things
simpler.  You can easily fit huge amounts of RAM.  You can cache more
stuff in memory, and address that memory sensibly.

In future I expect that these large address spaces will make userland
programs simpler too.  At Merjis I wrote programs which mapped 37.5 GB
files into memory for analysis (on machines with only 1 or 2 GB of
physical RAM).  Such things can't reasonably be attempted on 32 bit
machines.

Rich.

-- 
Richard Jones
Red Hat
-------------- next part --------------
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug