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
