| |||||||||||||
Pettenò: Debunking x32 mythsPettenò: Debunking x32 mythsPosted Jun 26, 2012 9:52 UTC (Tue) by butlerm (subscriber, #13312)In reply to: Pettenò: Debunking x32 myths by dlang Parent article: Pettenò: Debunking x32 myths
Assuming you have a 64-bit processor, the improvement relative to the 32-bit processor (or the 64-bit processor in a pure 32 bit mode) is basically irrelevant. No surprise there.
The question would be decided in both cases rather by the performance advantages of running 64 bit code with either 32 bit or 64 bit pointers. My understanding is that many Java applications slow down by as much as 20% simply by switching from a 32 bit JVM to a 64 bit JVM on the same machine.
Considering that the JVM implementation is gaining registers and register width, that result is rather remarkable. The only explanation appears to be that the cache impact of larger pointers in a Java environment is severe. Take a look at this for example:
Why 64-bit Java is slow
Naturally, the reasonable expectation should be that an x32 JVM would be considerably faster than both current IA-32 and current x86-64 JVMs. An ARM64 JVM with 32 bit pointers should be considerably faster than ARM64 JVM with 64 bit pointers for the same reason.
(Log in to post comments)
Pettenò: Debunking x32 myths Posted Jun 26, 2012 9:57 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
> An ARM64 JVM with 32 bit pointers should be considerably faster than ARM64 JVM with 64 bit pointers for the same reason.
that assumes that an ARM64 system has some advantage other than address space when compared to ARM32
none of the other processors that have both 32 bit and 64 bit modes (Sparc, Power, etc) have any advantage other than address space for their 64 bit modes, which is why it is still so common to see such systems running a 64 bit kernel with 32 bit userspace.
Pettenò: Debunking x32 myths Posted Jun 26, 2012 11:49 UTC (Tue) by mansr (guest, #85328) [Link]
ARM64 has 31 general-purpose registers (ARM32 has 14).
Pettenò: Debunking x32 myths Posted Jun 26, 2012 13:37 UTC (Tue) by butlerm (subscriber, #13312) [Link]
>that assumes that an ARM64 system has some advantage other than address space when compared to ARM32
That is beside the point - the issue is the relative performance of _ARM64_ code when compiled to use different pointer sizes. The advantage relative to ARM32 is irrelevant. ARM64 with 32 bit pointers must outperform ARM64 with 64 bit pointers on important workloads to be worth supporting at all.
There is plenty of evidence to suggest that will indeed be the case, and the difference between LP64 and L64P32 ("x32") on x86-64 will make that even more clear than the current major performance _loss_ one experiences when going from a pure 32 bit to pure 64 bit JVM.
Take a look at this:
64-bit Performance Thoughput/Memory Improvements in WAS7.0
The only way for them to get Websphere on a 64 bit JVM to approach the performance of Websphere on a 32 bit JVM was to use compressed references, i.e. smaller pointers. An L64P32 model on a 64 bit processor is essentially the same idea, and will make essentially the same improvement relative to LP64 without requiring developers to rewrite all the pertinent C code to use compressed pointers by hand.
Pettenò: Debunking x32 myths Posted Jun 26, 2012 13:46 UTC (Tue) by Flameeyes (subscriber, #51238) [Link]
> There is plenty of evidence to suggest that will indeed be the case, and the difference between LP64 and L64P32 ("x32") on x86-64 will make that even more clear than the current major performance _loss_ one experiences when going from a pure 32 bit to pure 64 bit JVM.
You should probably try to make sure you understand how the ABI works before trying to discuss it in details. It's ILP32, not L64P32 (i.e. "long" is also 32-bit).
As for the issue of compressed pointers in the JVM, it shows very well one thing: that you can easily solve the performance issue by making your code smarter, instead of breaking compatibility with what has be done up to now to make a new ABI.
Pettenò: Debunking x32 myths Posted Jun 26, 2012 19:11 UTC (Tue) by butlerm (subscriber, #13312) [Link]
>It's ILP32, not L64P32 (i.e. "long" is also 32-bit).
Thanks for the correction. I am not sure why anyone would want 32 bit longs on a 64 bit processor, unless there is a large code base out there that is lazy about using longs where ints would suffice.
Pettenò: Debunking x32 myths Posted Jun 26, 2012 19:28 UTC (Tue) by mansr (guest, #85328) [Link]
> unless there is a large code base out there that is lazy about using longs where ints would suffice.
Like SPEC2k.
Pettenò: Debunking x32 myths Posted Jun 26, 2012 19:50 UTC (Tue) by slashdot (guest, #22014) [Link]
Because almost all software supports x86, and thus supports ILP32, while it may fail to work on L64P32 since no existing architecture uses that.
Programs can still use 64-bit integers via long long, int64_t or intmax_t (and I'd guess intfast_t too?).
Pettenò: Debunking x32 myths Posted Jun 26, 2012 20:31 UTC (Tue) by butlerm (subscriber, #13312) [Link]
Almost all Linux software supports LP64, no? L64P32 would be almost identical, and from what I can see so far would eliminate most of the porting issues.
The struct timespec / timeval issues would go away, for example. The number of x32 specific syscalls required would go down. Problems with ioctl structure differences would be greatly reduced, as would problems porting LP64 code in general.
32 bit longs are the wave of the past. IA-32 is rapidly becoming obsolete. Why any special effort would be made to retain compatibility with ILP32 rather than with LP64 (as much as possible) is a mystery to me. The whole thing is going to run on an LP64 kernel with a parallel LP64 userspace in many cases, after all. 32 bit pointers can be a major improvement. 32 bit longs on a 64 bit architecture on the other hand just make life difficult without any substantive gains, so far as I can tell.
In any case ILP32 was a mistake. It should have been L64P32 to begin with.
Pettenò: Debunking x32 myths Posted Jun 27, 2012 1:50 UTC (Wed) by slashdot (guest, #22014) [Link]
The mistake was introducing the "char", "short", "int" and "long" keywords in C without specifying their meaning, despite the fact that there is no way to write a portable, correct and fast programs in such a language.
Again, almost all software supports 32-bit compilation, and since all existing relevant 32-bit ABIs (i.e. x86 and arm) are ILP32, it would be insane to use a different size for "long" than the rest of the 32-bit world.
New programs should never use the "long" keyword anyway and should instead use the typedefs in <stdint.h> which actually have a defined useful meaning.
Pettenò: Debunking x32 myths Posted Jun 27, 2012 2:51 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
>The mistake was introducing the "char", "short", "int" and "long" keywords in C without specifying their meaning, despite the fact that there is no way to write a portable, correct and fast programs in such a language.
So would you like to have "int" to be 18 bits or 36 bits in length?
Pettenò: Debunking x32 myths Posted Jun 27, 2012 4:30 UTC (Wed) by cmccabe (guest, #60281) [Link]
The C standard DOES specify the meaning of "char," "short," "int," and so forth. char is "the smallest addressable unit" (in practice always 1 byte), short and int are at least 2 bytes, and long is at least 4 bytes. It may not seem important to you now, but saving a few bytes definitely mattered back in the 1970s, when C was designed.
It would be nice for the stdint.h types to be built-in, and more widely used in some cases, but it's really not a big deal. There are always higher-level languages you can use if you don't want to deal with this stuff. Some of them even have unlimited length integers! The 70s are over, you know.
Pettenò: Debunking x32 myths Posted Jun 27, 2012 13:49 UTC (Wed) by nix (subscriber, #2304) [Link] char is "the smallest addressable unit" (in practice always 1 byte)It's not a matter of 'in practice'. char is, by definition, one byte long. In closely adjacent paragraphs of every C Standard ever published, sizeof() is defined as yielding 'the size (in bytes) of its operand', and then sizeof (char) is defined as returning 1. If you change sizeof (char), you change the definition of a byte on that platform's C ABI.
Pettenò: Debunking x32 myths Posted Jun 27, 2012 14:22 UTC (Wed) by mansr (guest, #85328) [Link] Whilechar is always and by definition one byte, a byte is not always one octet.
Pettenò: Debunking x32 myths Posted Jun 27, 2012 21:27 UTC (Wed) by nix (subscriber, #2304) [Link]
Exactly. Of course, on any reasonable platform these days (other than tiny DSPs normally not programmed in C at all), a byte is one octet, but in olden days this was not true. Of course by the time C was standardized at all it was pretty widely true, and by the time of C99 it was universal. But it wasn't always so.
Pettenò: Debunking x32 myths Posted Jun 27, 2012 21:45 UTC (Wed) by mansr (guest, #85328) [Link]
POSIX does mandate 8-bit bytes. As for those DSPs, a lot of code running on them is actually written in C. Only the critical parts are typically done in assembly.
Pettenò: Debunking x32 myths Posted Jun 29, 2012 4:57 UTC (Fri) by sethml (subscriber, #8471) [Link]
Check out the TI C2000 / TMS320 architecture. I've written a lot of C++ with 16-bit chars on that architecture over the past few years. Yes, it's a bit of a brain-dead architecture, but there are definitely archs with non 8 bit chars around still.
Pettenò: Debunking x32 myths Posted Jun 29, 2012 12:11 UTC (Fri) by nix (subscriber, #2304) [Link]
At least that's a multiple of 8. Are there any 9/18/36-bit bytes around these days? I hope not :}
Pettenò: Debunking x32 myths Posted Jun 27, 2012 8:38 UTC (Wed) by dgm (subscriber, #49227) [Link]
> The mistake was introducing the "char", "short", "int" and "long" keywords in C without specifying their meaning.
There was a reason for that. The intention was that they mapped cleanly to the word sizes of the underlaying architecture.
> despite the fact that there is no way to write a portable, correct and fast programs in such a language.
Absurd. C was invented for exactly that. The original UNIX code was written in PDP-7 assembly (a 18-bit machine), and later rewritten in C and ported to the PDP-11 (a 16-bit one). The first C version of UNIX was portable, correct _and_ fast. And all that in a newborn language that would be considered "crude" compared to today's C.
Pettenò: Debunking x32 myths Posted Jun 28, 2012 17:45 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]
Of course you say "use <stdint.h>" *now*. It wasn't officially part of C until C99 as I recall, and many codebases have code that's noticeably older than that. Furthermore, just because it was in C99 didn't mean all compilers had it in 1999. (Although I'll grant many had it before then.)
Pettenò: Debunking x32 myths Posted Jun 26, 2012 20:04 UTC (Tue) by Flameeyes (subscriber, #51238) [Link]
> Thanks for the correction. I am not sure why anyone would want 32 bit longs on a 64 bit processor, unless there is a large code base out there that is lazy about using longs where ints would suffice.
It's mostly not to break the assumption that sizeof(long) == sizeof(void*) which is true for _most_ Unix software. Although it's getting less common nowadays due to portability issues with Windows (Win64 being L32P64).
As mansr already pointed out, Spec2k makes wide use of long where int (or properly sized stdints) should be used, which is one of the reasons why its benchmarks are getting better results than they should theoretically get.
I can discuss this more, and I'll probably do so, in a blog post with more detailed discussion on the cache issue.
Pettenò: Debunking x32 myths Posted Jun 26, 2012 20:36 UTC (Tue) by butlerm (subscriber, #13312) [Link]
>Spec2k makes wide use of long where int (or properly sized stdints) should be used
It sounds like Spec2k should be rewritten to use int32_t instead of int, and int64_t instead of long, in any places where this might make a significant difference.
Pettenò: Debunking x32 myths Posted Jun 26, 2012 20:58 UTC (Tue) by Flameeyes (subscriber, #51238) [Link]
Yes, too bad that it's a quite secretive and closed-source benchmark, which is my first problem with the benchmark's numbers — took quite a bit of investigative work to actually find somebody who could confirm my hunch about longs.
Pettenò: Debunking x32 myths Posted Jun 27, 2012 3:11 UTC (Wed) by slashdot (guest, #22014) [Link]
You can apparently download an unlicensed copy for free from http://ks.tier2.hep.manchester.ac.uk/Mirrors/SPEC_CPU2006... and probably other places.
Pettenò: Debunking x32 myths Posted Jun 28, 2012 17:41 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]
I ran into plenty of it trying to port 32-bit software to a machine that had 40-bit 'long'. It breaks things in surprising ways. (Especially since sizeof(long) == 8 on said machine.)
Pettenò: Debunking x32 myths Posted Jun 26, 2012 10:43 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Java objects are very pointer-heavy. In fact, there's a special mode (CompressedOops) for 64-bit JVMs which compresses some 64 bit pointers into 32 bits. It often makes a significant performance difference.
Why 64-Bit Java Is Slow Posted Jun 27, 2012 1:28 UTC (Wed) by ldo (subscriber, #40946) [Link]
Maybe the reason for the slowdown going from x86 to AMD64 has to do with the fact that the Sun JVM is stack-based, not register-based. Maybe an interpreter with a register-based architecture, like Dalvik (as used in Android) will benefit better from 64-bit architectures.
Why 64-Bit Java Is Slow Posted Jun 27, 2012 1:47 UTC (Wed) by alankila (subscriber, #47141) [Link]
Java is defined as a stack machine. I don't think people execute it as a stack machine.
Why 64-Bit Java Is Slow Posted Jun 27, 2012 2:50 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
JVMs only use interpreter during startup. Then the code is JIT-compiled into native code and it doesn't matter at all whether the bytecode is stack-based or register-based. After all, they can be trivially interconverted.
|
|||||||||||||