[Gllug] 4G Memory Restriction

[Nix]

On Mon, 10 Apr 2006, Alain Williams suggested tentatively:
> On Mon, Apr 10, 2006 at 02:26:56PM +0100, Tet wrote:
>> On 4/10/06, Daniel P. Berrange <dan at berrange.com> wrote:
>> 
>> >You still really really want to use 64-bit kernel & OS if at all
>> possible though.
>> 
>> Note that this only applies to x86 compatible chips. On sparc64, it
>> turned out to be quite a big win to stick with a 32-bit userland with
>> a 64-bit kernel, unless your application *needed* to be 64-bit (large
>> databases and the like).
> 
> I guess that this is because 64 bit programs are bigger & use more dataspace,
> this means that the programs do not fit so nicely into CPU cache. Is that correct ?

Indeed. On x86-64, 64-bit programs have more registers available, but that's
not true on UltraSPARC, and in any case register pressure has never really
been the problem there than it is on the horribly register-deprived IA32 platform.

It's not just that instructions are bigger: pointers and alignments are
also twice the size. This leads to a quite substantial performance hit
from going 64-bit on UltraSPARC (I measured 25% or so for large GCC
compilations on an UltraSPARC-IIi.)

> But, if you run both 32 & 64 bit programs on your box you are going to need to have
> 2 copies of the C library (& others) in RAM....

Indeed. I ended up revising my autobuilder scripts so that they had a
`primary architecture' for which they built everything, and `secondary'
ones for which everything but the libraries got deleted automatically
except in a very limited set of cases (those 64-bit apps I actually
needed binaries for, for which I generally didn't build 32-bit versions
at all).

-- 
`On a scale of 1-10, X's "brokenness rating" is 1.1, but that's only
 because bringing Windows into the picture rescaled "brokenness" by
 a factor of 10.' --- Peter da Silva
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug