[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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.

I.e.:

- 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
    overhead

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

  - 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. processes.

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.

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]