x86-64 on i386 (was Re: Promoting i386 version over x86_64?)

[Chris Adams]

Once upon a time, Paul Jakma <paul at dishone.st> said:
> b) The amount of code on your system that is CPU bound and/or
>    memory-bound due to register pressure, to an extent that the x64
>    registers would make an appreciable difference is probably not
>    that significant
> 
>    - kernel hotpots
>    - graphics hotspots (X server perhaps)
> 
>    I havn't measured this, but nor have the people who say x86_64 is
>    faster AFAICT, and there's plenty of experience to say that most
>    software is far from CPU bound or memory bound.

As soon as you bring in even one 64 bit user-space program that is run
much, you've pulled in at least glibc and friends.  At that point, you
might as well run all (or as close to all as possible) 64 bit
user-space, because the libraries are shared (code will be in the cache,
etc.).

The only time my systems have run 32 bit code in several years is for
the Flash plugin (since the open-source plugins don't seem to be able to
keep up and since the 64 bit Adobe plugin doesn't seem to get the
security updates) and sometimes the Acrobat Reader plugin (since I've
run into websites that assume they can embed PDFs in the page and AFAIK
there's no plugin for Evince).

Since both cases are not all that common in my every-day use, I don't
hit the 32 bit libraries and such very often.  Running a single-arch and
single-lib system is more efficient.

As for the RAM overhead of 64 bit code vs. 32 bit code, I don't see it
much in the real world.  I have one 32 bit desktop at work, and
comparing the resident RAM usage between it and a 64 bit desktop, I
don't see much difference in the common desktop programs.  I know that
for some reason PHP on 64 bit arches bloats up significantly (at least
older versions), but that's the only major difference I've seen.

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.