Question

I noticed Sun is providing a 64-bit version of Java. Does it perform better than the 32-bit version?

Was it helpful?

Solution

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.

OTHER TIPS

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.

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?

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 it ends up being faster. The amount of handling of long types is usually small.

Of course it also depends upon the implementation of Java. As well as the compiler, you might find differences in the 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.

Some improvements: operations with doubles on 64 bits compute equally fast as floats on 32 bits, as well as operations on long at 64 bit compared to int.

So if you are running code with tons of longs you might see a real improvement.

I know that this question is quite old and the voted answers were probably correct at the time when they were written. But living in 2018 now, things have changed.

I just had an issue with a Java client application running on Win 10 64Bit on a Java 8 32Bit JVM. It was reading 174 MB of data from an HttpsURLConnection's InputStream in 26s which is awfully slow. The server and network were proven not to be the cause of this.

Thinking "Hey, there cannot be a huge difference between 32Bit and 64Bit JRE" it took some time until I tried having the very same code executed by a 64Bit JVM. Fortunately, in the end I did it: It was reading the very same 174MB in 5s!

I don't know if I could make it even faster, but the key take-away is this:

  • jre1.8.0_172 32Bit : 6.692MB/s
  • jre1.8.0_172 64Bit : 34.8MB/s

for the very same jar file being executed on Windows 10 64Bit.

I have no idea what could be the reason for this, but I can answer this question by "Yes, 64Bit Java is better than 32Bit Java". See also the numbers in the answer of my question regarding this issue.

My experience differs from the other answers.

Java 64bit may be faster than 32bit. At least with my tests it always was! The pointer argument is not valid when less than 4GB are used because then the 64bit-VM will also use short pointers internally. You get however the faster instruction set of the 64bit CPUs!

I tested this with Windows 7 and JDE1.8.0_144, but maybe the real reason are different internal JVM setting. When you use the 64-bit JVM it starts in "server" mode, while the 32-bit VM starts in "client" mode.

Yes, especially if your code is built to target a 64 bit platform.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top