Re: debian ppc64

[David Schleef <ds@schleef.org>]

On Mon, Dec 20, 2004 at 11:10:53PM +0100, Sven Luther wrote:
> Actually, as i recall, the 64bit code should be slower, since all pointers are
> now 64bit, and thus you have to transfer double amount of code from the ram
> and so on.

AIUI, 64-bit powerpc code is generally only slightly larger than
32-bit powerpc code.  Like, say, 1%.  (I'd be interested in actual
numbers, including differences in the sizes of individual sections
in a binary.)  Since the memory bandwidth of processors greatly
exceeds its usage by typical code (i.e., non-altivec and not
optimized by hand), I don't see the extra size of pointers
contributing to a memory bottleneck.  One exception is if you are
copying around massive arrays of pointers (or to a lesser extent,
structures containing pointers), which although not uncommon, is
probably not an interesting optimization case[1].

However, for a given cache size, any data containing pointers will
take up a larger chunk of cache.  64-bit processors generally have
larger caches to compensate for this, but for a given cache size,
one would expect 32-bit code manipulating lots of pointers to have
a higher hit-ratio, thus being faster.  Such increases would be
algorithm-dependent, hard to measure, and small (except in corner
cases).

I can really only think of two cases where 64-bit code could be
faster (not that it _would_ be in practise) -- 1) arithmetic on
64-bit types, and 2) optimized versions of strlen().

All in all, I'd consider it a wash, and would not be too concerned
about whether the system I was running was 32-bit native or 64-bit
native.  It would bother me (slightly), however, if there were two
versions of libraries competing for cache/RAM/disk space.



dave...

--
[1] One might consider significant copying of large arrays a bug in
the program itself.