Re: [gentoo-user] Re: x32 ABI

[Michael Mol]

On Tue, Jul 31, 2012 at 12:21 AM, Walter Dnes <waltdnes@××××××××.org> wrote:
> On Tue, Jul 31, 2012 at 05:47:22AM +0300, Nikos Chantziaras wrote
>
>> That's a problem with x86, not x32.  x32 is a 64-bit mode.  It's a
>> new ABI :-)
>
>   The original poster asked...
>
>> What are the benefits and drawbacks of using the x32 ABI, other
>> than the obvious "experimental" cautions?  I currently do not have
>> a computer with more than 4GB of ram, and one only has 2GB (used as
>> a media center).
>
>   x32 is a backwards compatability shim for use under 64-bit mode.  The
> point I was trying to make was that the minimum memory where 64-bit has
> clear advantages is 4 gigs.  If you have 3 gigs or less, you can stick
> with 32-bit mode, and x32 libs become moot.

The only reason they're the "clear" advantages is because it's much,
much harder to adequately describe the advantages given in things such
as:

* Doubling the number of general-purpose registers. The compiler has a
_lot_ more wiggle room for efficiently arranging data during
execution.
* Doubling the number of SSE registers. You can process a lot more
data a lot more quickly without the round trip latency of getting to
your GPU.
* Decreasing the pressure on memory allocators to allocate memory in a
way that avoids fragmentation. This is a function of the larger
virtual address space, and has nothing to do with the amount of
physical memory you have.
* Changing the calling convention to reduce function prologues, and to
enable some fancy optimizations.

It's also commonly forgotten that a process's address space is divided
between userspace and kernelspace; the kernel takes its piece of your
process, too, meaning that even if you have 4GB of RAM, you can't
create a 3GB heap allocation or mmap 3GB of data. And that has nothing
to do with the architecture's mapping of your video card's memory into
your system's physical address space.

People pound on the "3-4GB of RAM, and you should use x86_64" because
it was the easiest way to justify x86_64 to people when it came out;
AMD didn't retain full compatibility with x86 when the processor is in
long mode, nor does the compatibility mode (which is what x86 ELF
binaries running under an x86_64 kernel) have all of the features of
the legacy x86 ISA. AMD discarded them for a variety of reasons, even
though it meant breaking compatibility with a lot of code that was out
there. These days, that doesn't seem like a big deal, but there was
doubt at the time as to whether or not AMD64 would take off. Even
Microsoft bet the wrong way on that one, initially announcing its only
64-bit platform would be Itanium.

To get around the bad press, people pointed to RAM. AMD64 long mode
carried real benefits over PAE for enterprise applications, and AMD's
parts kept things like instruction reordering, whereas Intel's Itanium
ditched it, hoping that compilers would cover the difference. So, for
enterprise, where you often had servers with a whopping 16GB of RAM
and terabytes of mmap()-able data, the improved address space was a
major boon.

Meanwhile, home users just kinda trotted along. It took Unreal's
developers complaining they needed to be able to fit gigabytes of
texture, object and model data into RAM before you really started
seeing AMD64 pick up steam on home systems. Even then, Windows desktop
users didn't get real 64-bit support until Vista. (Yes, there was a
64-bit version of XP, but driver support there was and is abysmal).
But by the time users started installing Vista, they'd already had 4GB
of RAM in their systems and were wondering why their BIOS POST
sequence would say they only had, say, 3.6GB.

So, again, people started pounding on the RAM barrier as a reason to
switch to AMD64. People in userland still didn't notice things like
additional registers, because they didn't (and don't) understand them.
It's not something they see as as part of their POST process or as a
visible part of a spec sheet, so it's not something they jockey over.
But it's far more important than whether a part has a 90nm feature
size or a 45nm feature size.

It's true enough; if you have enough RAM, you certainly should be
using x86_64. The opposite isn't true, though; even if you don't have
enough RAM to demand 64-bit pointers, that doesn't mean you shouldn't
be using x86-64.

-- 
:wq