Re: debian ppc64

[Sven Luther <sven.luther@wanadoo.fr>]

On Tue, Dec 21, 2004 at 06:56:18PM -0800, David Schleef wrote:
> 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().

Well, for 2), altivec should be a better optimizer, right ?

Friendly,

Sven Luther