LInux 3.4 Kernel Has x32 ABI Support

[allquixotic]

Thanks for approving!

He was being sarcastic, dummy And just to prove how ignorant you are, here's a tiny list of legitimate applications/app categories that easily can use more virtual address space than can be mapped with 32-bit pointers:

• All digital audio workstations (e.g. Ardour, Audacity)
• GIMP (very easy to do if editing digital camera images in their original resolution)
• LibreOffice/OpenOffice (big databases, huge documents, large database driver caches, etc)
• Simulations, e.g. OpenSimulator (server-side), Second Life client (client-side)
• Application servers, e.g. JBoss, Glassfish, Tomcat
• A non-modular browser with a zillion tabs open (okay, less likely than some of the above)
• Video transcoding / capture software, or mostly anything that deals with video, esp. real-time
• The LZMA/LZMA2/PPMd compression algorithms, in compression mode, with maximum/ultra compression quality
• Most any scientific computing application (if it uses OpenCL and pegs your entire CPU, that's a good hint)

Out of this list, "normal users" would probably only ever use the first three on the list, and maaaaybe video transcoding, but still... whether or not these apps actually run OOM is irrelevant. The point is, their performance could drastically be improved on a system with more than 4GB of RAM if it can use all that address space. Many applications are cleverly coded so that they will sacrifice CPU time or even store temporary results to disk, in order to avoid using up all the virtual address space. But, while this clever coding makes the application stable on a 32-bit system, it comes with a huge performance hit. For example, writing to disk is 20 times slower (on average; SSDs notwithstanding) than writing to RAM. If you could just use a little more RAM, your app would run 20x faster!

I have a desktop with 16 GB of RAM, and it wasn't that expensive. I can now afford buying 32 GB of RAM, but I'd need to get a new motherboard to slot it There are even laptops these days that can go between 8 and 24 GB of RAM depending on how large of a laptop you want. RAM is cheap and extremely useful; not being able to use it is a sad waste. Set your memory-hungry apps free!

The above reasons are why I think 32-bit is just not going to have a lasting future for the general purpose desktop, because desktops are where all the high-capacity RAM is being bought, and (increasingly) used. That said, however, not even the most insane user of a smartphone or tablet is going to try and use that much memory, so 32-bit is fine for ARM devices that, at the extreme high-end, only have 2GB of RAM today. ARM is at least a decade away (maybe more like 15 years) from even needing 64-bit for any applications on Android or similar. For x86_64, the need for 64-bit is real, and it's here today.

[stqn]

I was sure someone would come up with a useless list of applications using more than 1 GB of ram... I was obviously talking about ?normal? use of a computer, not professionnal and specific work.

Video transcoding doesn?t take more than a gig here, definitely not more than 2. Nor does compiling ?normal? programs, using Firefox with 50 tabs or Audacity. My parents use OpenOffice on a computer with 1 GB RAM and it doesn?t need 3 GB of swap, no. No sane person would use xz at the maximum compression setting; it?s already too slow at the default with little benefit over gzip.

Buying something and creating waste because it?s ?cheap? is stupid and saying that everyone can/should do the same even more so.

[chithanh]

Funny that you mention Firefox. Mozilla has run repeatedly into address space limits when using profile guided optimization during Firefox build. As Web 2.0 applications become increasingly complex, my guess is that the browser will be the next application to require 64 bit (after image and video editors).

Regarding gzip vs. xz, the difference can be staggering.

[allquixotic]

I was sure someone would come up with a useless list of applications using more than 1 GB of ram... I was obviously talking about ?normal? use of a computer, not professionnal and specific work.

Video transcoding doesn?t take more than a gig here, definitely not more than 2. Nor does compiling ?normal? programs, using Firefox with 50 tabs or Audacity. My parents use OpenOffice on a computer with 1 GB RAM and it doesn?t need 3 GB of swap, no. No sane person would use xz at the maximum compression setting; it?s already too slow at the default with little benefit over gzip.

Buying something and creating waste because it?s ?cheap? is stupid and saying that everyone can/should do the same even more so.

Talking only about extremely basic use cases that your grandparents would use because they're "normal" is stupid and saying that everyone can/should do the same even more so.

[mrugiero]

No sane person would use xz at the maximum compression setting; it?s already too slow at the default with little benefit over gzip.

Everytime I compress something, I use 7z at maximum compression...

Creating waste because it's cheap is stupid indeed. Assuming everyone makes the same use than you, is stupid too.

[smitty3268]

I was sure someone would come up with a useless list of applications using more than 1 GB of ram... I was obviously talking about ?normal? use of a computer, not professionnal and specific work.

Here's the thing - with those "normal" uses of a computer, no one is going to notice any difference between x32 and x64 anyway. So why not just go with the more future-proof and already widespread x64?

I think the x32 code is being strongly pushed by the enterprise DB/app stack providers, who live and die by benchmark numbers, not the average desktop user.

[mrugiero]

Here's the thing - with those "normal" uses of a computer, no one is going to notice any difference between x32 and x64 anyway. So why not just go with the more future-proof and already widespread x64?

I think the x32 code is being strongly pushed by the enterprise DB/app stack providers, who live and die by benchmark numbers, not the average desktop user.

I think having the option is good. I'm actually thinking in switching x32 in one of my boxes if it becomes supported by a Debian based distribution, since that computer has only 1GB, and IIRC the max ammount the mobo supports is 2GB, so x32 fits it perfectly. I might even use it on other boxes as well.
Anyway, I think the default should be the more future-proof, as you said.

On the other hand, if I understood it correctly, once kernel and compilers supports it, it should be just a build time issue for userland, so for distros it would be only an extra build. Am I right?

[XorEaxEax]

Everytime I compress something, I use 7z at maximum compression...
Creating waste because it's cheap is stupid indeed. Assuming everyone makes the same use than you, is stupid too.

Same here, given that when I compress something it is in order to archive it for possible future use then I want it to use as little space as possible.

Here's the thing - with those "normal" uses of a computer, no one is going to notice any difference between x32 and x64 anyway. So why not just go with the more future-proof and already widespread x64?

I think the x32 code is being strongly pushed by the enterprise DB/app stack providers, who live and die by benchmark numbers, not the average desktop user.

Well if we are talking ~15% speedup on computionally intensive apps then certainly it will be 'noticeable'. Lot's of people do things like encoding, rendering, compression on a regular basis and won't scoff at an 15% performance increase. AFAIK the only technical downside with x32 is that the applications will only be able to address 4gb, I have a 4gb and an 8gb machine at home, I run both of them without swap and I compile, encode, render, 3d model, gimp/inkscape/mypaint, emulate, browse with tons of tabs open and almost always with several instances running and I have no RAM problems on either machine. Only time I can recall an app segfaulting because of lack of ram was when I was testing 7z with a very large dictionary. Granted I run a lean system, my current Openbox/Tint2/Conky/Feh/Compton setup only uses 133mb ram in 64bit so there's plenty available for apps.

Another plus with x32 apart from possible performance increase is that the binaries/libs will be smaller and thus use less ram.

But yes, the 'average' desktop user will have no urge to have x32, still I think we will see an interest among 'power-users' even on the desktop, that is if the reported performance increase is actually correct.

[XorEaxEax]

On the other hand, if I understood it correctly, once kernel and compilers supports it, it should be just a build time issue for userland, so for distros it would be only an extra build. Am I right?

AFAIK yes, 3.4 kernel will have x32 and GCC apparently has x32 support with some fixes needed for glibc IIRC so in essence you would need to have your 64bit kernel compiled with support for x32 and then compile apps and the libs they need against the x32 ABI.

[mrugiero]

AFAIK the only technical downside with x32 is that the applications will only be able to address 4gb

Since you seem to understand the subject, I'll ask you.
Is that limit only per application, or overall? Does x32 limit the total addressable memory to a (significantly) smaller value than x64?
I'm aware that IA32 architechture limits the addressable memory to 4GB and the memory per app to around 2GB (I don't fully recall the value), if I got the correct data.