Intel Is Trying To Support The x32 ABI For LLVM/Clang

[smitty3268]

Firefox 30 was chewing up > 6 GB of RAM just yesterday, due to a mix of javascript overkill and flash taking a giant dump on gaming [all on Debian Unstable/Experimental].

95% of firefox users are running a 32bit process on windows, so 4GB is obviously plenty for the vast majority of people.

Throw in any scientific application and the 4GB ceiling is retarded. Same with Solid Modeling, Audio Mixing, you name it.

Sure. Which is used by what, 1/10th of 1 percent of people? Probably a lot less. I'm not saying nothing needs 4GB - just like i'm not saying nothing will benefit from the 32-bit pointers - it's just that in both cases the benefits will only affect a very small percentage of people.

Sorry, but the vast majority of applications will soon be routinely wanting to use larger memory limits, especially with every numbnut wanting to make Web Apps approach the speeds of traditional applications space, just with an overkill of abstraction.

Don't be ridiculous. Abstractions don't add GB of memory use.

[discordian]

Another 2 users (mcirsta and discordian) that don't understand shit about x32...

Let me put it in clear terms:

x32 is __not__ 32 bit libs or even a continuation of i386.
Please.. Get it in your head!
If you still don't get it then read it like this: x32 is a means to optimize the memory usage in x64. Your app stays 64 bit!. The statement is not completely accurate, but apparently some people only understand simple short lines.

Funny, I never said that. So you have reading comprehension issues?
x32: allows apps with 32 and 64 bit pointers, without different CPU Modes. You need, for the most part differently compiled libraries for each - x32 and 64bit
amd64: the common 64bit mode, needs 64bit libs
x86: the common 32bit mode, needs 32bit libs (different then x32 libs)

this makes 3 different kinds of libraries, you might have to use if you eg. use x32 and 64bit apps and use some precompiled stuff like Skype.

[Kraut]

Didn't know about x32 so far. The best usage case I can come up with is threaded workload that does not depend on any system libs. And let this x32 threads run beside a 64bit main thread to get some caching benefits.
What nobody mentioned is that you only get 4GiB of virtual address space. And I suspect you share like 1GiB for the Kernel interface.

[chithanh]

Ugh, so much misinformation here.

x32 is basically x86_64 just with 32 bit pointers. It requires an x86_64 kernel.

x32 will reduce memory usage, and especially memory bandwidth usage by applications. For most applications though, the resulting reduction and performance benefit is hardly measurable, while a few synthetic benchmarks benefit greatly.

x32 is pushed by Intel predominantly for mobile (phone/tablet SoCs). Why is that? Because mobile CPUs have rather small caches and little memory bandwidth and need to share the latter with the GPU even.

x32's main use case is not the desktop. There will probably never be an x32 Skype, and desktop browsers are well beyond 4 GB memory under heavy usage. Then you have the problem that applications need to be ported to x32 and JIT compilers need to be modified to output x32 code.

A must read: https://blog.flameeyes.eu/2012/06/debunking-x32-myths

[erendorn]

Firefox 30 was chewing up > 6 GB of RAM just yesterday, due to a mix of javascript overkill and flash taking a giant dump on gaming [all on Debian Unstable/Experimental].

Throw in any scientific application and the 4GB ceiling is retarded. Same with Solid Modeling, Audio Mixing, you name it.

Sorry, but the vast majority of applications will soon be routinely wanting to use larger memory limits, especially with every numbnut wanting to make Web Apps approach the speeds of traditional applications space, just with an overkill of abstraction.

Most scientific applications I work with (simulation, stats, and number crunching) don't even need 1Gb of RAM. They would benefit from extra speed though, so x32 versions would certainly be welcome.

[bnolsen]

Most scientific applications I work with (simulation, stats, and number crunching) don't even need 1Gb of RAM. They would benefit from extra speed though, so x32 versions would certainly be welcome.

The scientific applications I work on in some cases require 50G or more.

I agree with other posters. Intel should just drop this x32 push. There's no reason developers should even have to think about this memory limitation stuff. And oodles of ram today costs almost nothing. If you want 32 bit mode, then compile 32 bit mode.

Another sugestion would be to add new march and mtune flags to gcc32 to allow for the extra instruction registers and instructions. 32bit pointers == 32 bit architecture. So who cares if some pentium4 can't run the stuff? Does 32bit mode in intel processors have some magic that shuts off substantial parts of the processor?

[erendorn]

The scientific applications I work on in some cases require 50G or more.

I agree with other posters. Intel should just drop this x32 push. There's no reason developers should even have to think about this memory limitation stuff. And oodles of ram today costs almost nothing. If you want 32 bit mode, then compile 32 bit mode.

Another sugestion would be to add new march and mtune flags to gcc32 to allow for the extra instruction registers and instructions. 32bit pointers == 32 bit architecture. So who cares if some pentium4 can't run the stuff? Does 32bit mode in intel processors have some magic that shuts off substantial parts of the processor?

1) The fact that some scientific applications require 50Gb or more means that there is a need for x86_64 ABI. It does certainly not mean that there is no need for x32 ABI.
In other words, my point, which is "I use apps that could work better in x32, so x32 is not useless" is a valid point, whereas your point, which is "I use apps that would not work better in x32, so x32 is useless" is illogical. I hope you understand that.

2) Can you tell me where I can buy oodles of processor cache? I'd also like a memory bandwidth improver, and a memory lag reducer. All of them cheap, if possible.

3) I think you are confusing architectures and ABI, and what processors are targeted. Have a look at what x32 is before you propose nonsensical stuff.

[paulpach]

To me, this sounds like trying to use 64 bit features on 32 bit architectures.

It is the complete opposite. This is about using 32 bit features in a 64 bit architecture. This mode only runs in 64 bit machines.

The main advantage of 64 bit, is that it has more and bigger registers. The main advantage of 32 bit architecture is that pointers only need 4 bytes instead of 8, so 32 bit code tends to use less memory. x32 is a mode that tries to get the best of both worlds, it runs in 64 bit architectures and allows you to use the extra registers, which can really help performance, while keeping pointers at 32 bits and saving memory and cache coherence.

What is the trade off? well, if you have 32 bit pointers you can only address 4GB of RAM from the same process. In practice it is very rare that a single process would need that much memory, you would normally have lots of small processes, so this is not a limitation for most software.

I don't know why people need to be so rude in phoronix, a simple clarification is enough.

[name99]

Ugh, so much misinformation here.

x32 is basically x86_64 just with 32 bit pointers. It requires an x86_64 kernel.

x32 will reduce memory usage, and especially memory bandwidth usage by applications. For most applications though, the resulting reduction and performance benefit is hardly measurable, while a few synthetic benchmarks benefit greatly.

x32 is pushed by Intel predominantly for mobile (phone/tablet SoCs). Why is that? Because mobile CPUs have rather small caches and little memory bandwidth and need to share the latter with the GPU even.

x32's main use case is not the desktop. There will probably never be an x32 Skype, and desktop browsers are well beyond 4 GB memory under heavy usage. Then you have the problem that applications need to be ported to x32 and JIT compilers need to be modified to output x32 code.

A must read: https://blog.flameeyes.eu/2012/06/debunking-x32-myths

To add to the (remarkably few) facts in this thread, x32 buys you about 10% in performance over x64. That's not bad, especially in contexts like phone and tablet where large address spaces are unlikely to be necessary for a while. Against that, you have the cost of a second set of libraries which has its own RAM footprint AND adds to the already massive Windows storage bulk. I understand why Intel is pushing this as a fallback plan, but I'm not sure who they expect will actually adopt it. Maybe the primary place it's useful is in network appliances which will be running a limited and unchanging set of Linux apps and Intel is trying to compete in that space. (Good luck, given the quality of the offerings with ARM, PPC and MIPS ISAs!)

More interesting (because more likely to actually have real world consequences) is the question of whether Google will make an aggressive attempt to use pointer compression within 64-bit ART. It MIGHT be possible to do something like that, given the level of abstraction that ART provides, and thus explicit "boundary points" at which you would need to perform pointer fixups. Of course, if you do use pointer compression, you give up the ability to use the high bits in your pointer as object flags. I don't know if Android exploits this, but Apple obviously does, and aggressively so; which means I can't see them making any attempt at pointer compression.

From the LLVM dev list a few days ago:

Just a datapoint on why x32 is interesting.

I compiled clang on a ubuntu vm in 32 bits, 64 bits and x32. As a
simple benchmark I then compiled gcc.c from
http://people.csail.mit.edu/smcc/pro...-file-programs. The
results were (best of 3 runs, user time)

32:
0m19.529s

64:
0m17.044s

x32:
0m15.768s

[chinoto]

At first I was just going to go with "I don't really understand this, but it sounds like something good is happening, so I'm happy". Now that I've read the comments, I get it and think it's a great thing to have, now we just need it to be implemented.