I noticed sun is providing a 64bit version of Java. Does it perform better than the 32bit version?
+8
A:
Define your workload and what "perform" means to you.
This is sort of a running annoyance to me, as a performance geek of long standing. Whether or not a particular change "performs better" or not is dependent, first and foremost, on the workload, ie, what you're asking the program to do.
64 bit Java will often perform better on things with heavy computation loads. Java programs, classically, have heavy I/O loads and heavy network loads; 64 bit vs 32 bit may not matter, but operating systems usually do.
Charlie Martin
2009-02-26 04:09:57
Can't believe the answer is this simple. For me 64 bit is more suited to loads where 64-bit address space is a help and not a hindrance. There is a 2x cost for every pointer, which can be outweighed if you need LOTS of data. a web server object cache is a great example of where 64 bit wins.
Cheeso
2009-02-26 15:45:00
Sun says that this answer is wrong.
Darron
2009-02-26 22:06:51
Darron, you have a citation for that? Since I worked for Sun for 10 years, and since the answer is basically "it depends on the workload and what kind of performance you care about measuring", I -- how to put this -- don't believe you.
Charlie Martin
2009-02-26 22:15:09
@Charlie Martin: see the HotSpot FAQ at http://java.sun.com/docs/hotspot/HotSpotFAQ.html#64bit%5Fperformance
Darron
2009-02-26 23:44:30
I suspect the cause is that most of the time the increased sizes of objects (because of pointer sizes) swamps the benefits from more efficient operations on longs and doubles.
Darron
2009-02-26 23:46:14
Okay, I see how you got there, but it still comes down to the 64-bit will perform better on *some* workloads, *worse* on others, and it's a wash on yet others. In other words, "dependent first and foremost on the workload".
Charlie Martin
2009-02-27 00:34:54
A:
Yes, especially if your code is built to target a 64 bit platform.
Chris Ballance
2009-02-26 04:10:25
+2
A:
On most CPU architecures 32-bits is faster than 64-bit, all else being equal. 64-bit pointers require twice as much bandwidth to transfer as 32-bits. However, the x64 instruction set architecture adds a bit of sanity over x86, so ends up being faster. The amount of handling of long types is usually small.
Of source it also depends upon the implementation of Java. As well as the compiler you might find differences in implementation, for instance NIO assumes 64-bit pointers. Also note that Sun previously only shipped the faster server HotSpot implementation for x64. This meant that if you specified -d64, you would also switch from client to server HotSpot, IIRC.
Tom Hawtin - tackline
2009-02-26 12:26:57
A:
some improvements: operations with doubles on 64bit compute equally fast as floats on 32 bits, as well as operations on long at 64bit compared to int.
so if you are running code with tons of longs you might see a real improvement.
Andreas Petersson
2009-02-26 12:45:53
+5
A:
Almost always 64 bits will be slower.
To quote Sun from the HotSpot FAQ:
The performance difference comparing an application running on a 64-bit platform versus a 32-bit platform on SPARC is on the order of 10-20% degradation when you move to a 64-bit VM. On AMD64 and EM64T platforms this difference ranges from 0-15% depending on the amount of pointer accessing your application performs.
There are more details at the link.
Darron
2009-02-26 13:04:06
+1
A:
64-bit perform better if you need much more than 1.2 GB. On some platforms you can get up to 3 GB but if you want 4 - 384 GB for example, 64-bit is your only option.
I believe Azul supports a 384 GB JVM, does anyone know if you can go higher?
Peter Lawrey
2009-02-26 20:01:41