Not logged in
Log in now
Create an account
Subscribe to LWN
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
Little things that matter in language design
That way I get pretty much the same benefit, but without even the least tiny bit of headache that I would get by trying to use x32 on anything.
Pettenò: Debunking x32 myths
Posted Jun 26, 2012 8:00 UTC (Tue) by dlang (✭ supporter ✭, #313)
It's clear why x32 has significant performance advantages over plain 32 bit x86 mode, what's less clear are the benefits when compared to 64 bit mode.
Posted Jun 26, 2012 9:30 UTC (Tue) by tao (subscriber, #17563)
The main use for x32 isn't for regular desktops. For regular desktops/servers the advantage of x64 is clear (being able to address more than 4GB/process).
On an embedded device, which probably doesn't even have 4GB of RAM, however, the question is rather: what benefits would x64 have compared to x32?
Posted Jun 26, 2012 9:53 UTC (Tue) by dlang (✭ supporter ✭, #313)
however, you are missing significant benefits of x32 vs traditional 32 bit
added total address space (since you are using a 64 bit kernel)
added per-process memory (4G instead of 2G)
twice the number of registers.
ability to rely on advanced CPU features (compared to i86)
64 bit commands.
64 bit time_t
moving from x32 to full 64 bit adds
increased per-process address space (beyond 4G) with the drawback of increased pointer size (and the effects this can have on cache pressure)
The advantages of moving off of pure 32 bit are pretty clear, the only drawback being that it's new and has less testing.
however, when comparing x32 and 64 bit, it's less clear if the overall win is going to be in the address space or the cache efficiency.
unless, as you point out, the system just doesn't have enough ram to use the additional address space, and that point is probably higher than most people thing. I expect it's probably at 8+GB of ram, not at 4G of ram. Remember that memory used for disk caches, the kernel, housekeeping apps, etc can easily use the ram beyond what the 'main' app of the system uses, even assuming that the 'main' app of the system is a single process.
If the 'main' app of the system in multiple processes not a single process with multiple threads, which is a fairly good thing to do when faced with multi-core CPUs anyway, the amount of memory in a 'typical' system before it really needs 64 bit addressing in userspace can easily go beyond 16G
on the other hand, some people will have apps that really want more address space, even on low-memory machines (it may be more efficient to address the memory sparsely than to add the complication to use it more efficiently)
Posted Jun 26, 2012 12:59 UTC (Tue) by tao (subscriber, #17563)
Nowhere did I question the merits of x64 (or x32, for that matter) over x86.
As far as address space goes though, you can use a 64-bit kernel even with x86.
Posted Jun 26, 2012 16:00 UTC (Tue) by Otus (guest, #67685)
It's the same with normal 32-bit userspace on a 64-bit kernel.
> added per-process memory (4G instead of 2G)
> twice the number of registers.
> ability to rely on advanced CPU features (compared to i86)
With amd64 you can only rely on SSE and SSE2 being available. I assume it's
the same with x32? You'll still need some sort of cpuid checks for more
recent features and you can do that on normal 32-bit as well.
(Or you can just tell the compiler to assume they are available.)
> 64 bit commands.
What do you mean?
> 64 bit time_t
Posted Jun 26, 2012 19:05 UTC (Tue) by dlang (✭ supporter ✭, #313)
> What do you mean?
My understanding is that with x32 the compiler can use CPU instructions that operate on 64 bit items.
Posted Jun 27, 2012 14:29 UTC (Wed) by hummassa (subscriber, #307)
I couldn't parse your "yes"es...
Did you mean "yes, I know that using x32 instead of ia32 I have access to twice the number of registers"?
Posted Jun 27, 2012 19:42 UTC (Wed) by Otus (guest, #67685)
Listing the advantages of x32 over 32-bit/32-bit or 64-bit/64-bit
user-space/kernel is misleading, because 32-bit/64-bit is the one it needs
to really improve upon to be worth the effort.
Posted Jun 27, 2012 21:28 UTC (Wed) by nix (subscriber, #2304)
Posted Jun 27, 2012 21:51 UTC (Wed) by mansr (guest, #85328)
Posted Jun 27, 2012 21:58 UTC (Wed) by dlang (✭ supporter ✭, #313)
Posted Jun 27, 2012 22:20 UTC (Wed) by mansr (guest, #85328)
Posted Jun 27, 2012 22:35 UTC (Wed) by dlang (✭ supporter ✭, #313)
Posted Jun 27, 2012 23:02 UTC (Wed) by mansr (guest, #85328)
Posted Jun 27, 2012 23:50 UTC (Wed) by dlang (✭ supporter ✭, #313)
In the past, some distros had kernels for i386, i486, i586, and i686. it was a major headache and not very effective. In many ways doing an entire new ABI is easier to deal with than dealing with a slight variation to an existing one.
Posted Jun 27, 2012 23:59 UTC (Wed) by nix (subscriber, #2304)
(But with regard to the flag which *does*, everything you say is true. glibc's hwcaps mechanism will allow you to implement 'slight variation on instruction set', allowing some but not all libraries to have alternate versions for various hwcaps, plus 'tls' as a now-obsolete special case. On x86, this tends to get used to compile different x86-32 binaries for machines supporting versus not supporting the CMOV instruction; on e.g. SPARC64, it is (or was) used to provide alternate versions of libraries for the SPARCv9 32-bit instruction set, which is much like x32 except ABI-compatible with the usual SPARC 32-bit ABI -- all the SPARCv9 registers plus integer multiply and divide instructions, imagine that! You can't use the hwcaps mechanism to support different ABIs though, because nothing stops a hwcapped library calling a non-hwcapped one, or vice versa.)
Posted Jun 28, 2012 5:33 UTC (Thu) by Otus (guest, #67685)
Posted Jun 27, 2012 23:35 UTC (Wed) by nix (subscriber, #2304)
The option you're thinking of is -msseregparm, which elicits warnings whenever you use it because it breaks the ABI, meaning that you must link every single thing that you pass floating-point arguments to or receive floating-point return values from with the same option.
This includes libm, which you'll probably need to hack to expect its arguments in SSE registers, since a lot of its 32-bit code expects to receive them in x87 -- and sacrifice compatibility with everyone else's 32-bit x86 code, since nobody else uses that option. If you're doing that these days, you may as well use x32. :)
Posted Jun 28, 2012 0:42 UTC (Thu) by mansr (guest, #85328)
Posted Jun 28, 2012 14:23 UTC (Thu) by nix (subscriber, #2304)
Regarding inlined math operations, yes, quite a few can be inlined. A lot of the more complex stuff is just too large to usefully inline, though :( but I suppose the really common things generally are inlined (sqrt() being rather more commonly used than, e.g., y1f()).
Posted Jun 26, 2012 10:11 UTC (Tue) by ebirdie (subscriber, #512)
Posted Jun 26, 2012 11:21 UTC (Tue) by drag (subscriber, #31333)
Posted Jun 26, 2012 19:20 UTC (Tue) by butlerm (subscriber, #13312)
Posted Jun 26, 2012 21:00 UTC (Tue) by Flameeyes (subscriber, #51238)
So the (IMHO little) benefit on the data cache utilisation is made useless by the huge effort and compatibility issues brought in by having a full new ABI. Which is probably why the original presentation "sold" x32 as a closed-system ABI, not a generic one, like it seems people expect it to be right now.
Posted Jun 28, 2012 17:49 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds