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

Paul Jakma paul at dishone.st
Tue Dec 15 21:28:10 UTC 2009

On Tue, 15 Dec 2009, Jon Masters wrote:

> But again, Apples to Oranges. x86_64 (we should formally call it "Intel
> 64", or similar, since I'm not aware of x86_64 having a formal blessing)
> doesn't have the fixed instruction width that you get on most RISC ISAs.

It's not about the instruction set.

If you look back at the posts, from myself and the poster who gave a 
toy test case, the extra memory usage is from data, not from 
programme text. Programme text is not too significant in size when 
compared to data (about a 10:1 data:text ratio for cases I've looked 
at). So the instructions being compact is simply not very relevant - 
pointers and longs in *data* double up in size on 64bit. (This 
transcends specific ISAs..).

> the US, but here at least someone drew my attention to a 
> ludicrously cheap laptop on sale last weekend that also had 3GB of 
> RAM installed.

Right. I.e. a 64bit *kernel* is very useful (and much faster than a 
PAE one). That's precisely what I am arguing for.

Again, there is a difference between aggregate usage (e.g. of RAM) 
and per-process memory requirements, similarly for performance. I.e. 
in the aggregate, a system can make good use of *both* 32 and 64 bit.


- In the aggregate, systems now need to make efficient use of >3GB
   of memory

   - PAE (slow, other problems)
   - 64bit - more and more systems have this, it'd be nice to be able
     to use this with a 32bit install.

- On a per-process basis, few processes need 64bit pointers

   - those which do, can easily be 64bit on a 32/64 system.
   - those which can be 32bit can avoid a circa 30 to 60% memory

- On a per-process basis, few processes need the advantages of

   - I am incredulous at the people who keep arguing that "x86-64 is
     better" because it has PC-relative addressing, or because the ABI
     is pass-by-register by default. I am extremely sceptical that
     these respondents would be able to distinguish between a 32bit
     and a 64bit "cp" or "nautilus" or "ls" or "gnome-panel" or ... etc.

     It'd be interesting to see if this applied even to browsers.
     (E.g. Chrome on 32bit is extremely fast, hard to see that it'd
      get much faster on 64. Firefox is slow on 64bit too).

   - those processes which do, can be 64bit

I would like to have the advantages of *both* 32 and 64bit, as and 
where each one is appropriate. I'd like to be able to use that 30-60% 
of memory on more VMs, e.g., rather than bigger gnome-*, etc. 

A lot of respondents have argued as if this is a binary matter, 
approaching the debate as if it's an either-or choice between 32 OR 
64, which was not my intention at all.

And again, far from being some incredibly difficult thing that I'm 
asking for, the support is pretty much 99.9% there..

Anyway :)

Sorry for extending this thread, but it seemed I miscommunicated in 
previous emails and failed to get the basic points across properly.

Paul Jakma	paul at jakma.org	Key ID: 64A2FF6A
Seeing is believing.  You wouldn't have seen it if you hadn't believed it.

More information about the fedora-devel-list mailing list