Why is the 64bit JVM faster than the 32bit one?

Without knowing your hardware I'm just taking some wild stabs.

Without knowing your hardware I'm just taking some wild stabs Your specific CPU may be using microcode to 'emulate' some x86 instructions -- most notably the x87 ISA x64 uses sse math instead of x87 math, I've noticed a %10-%20 speedup of some math-heavy C++ apps in this case. Math differences could be the real killer if you're using strictfp. Memory.64 bits gives you much more address space.

Maybe the GC is a little less agressive on 64 bits mode because you have extra RAM. Is your OS is in 64b mode and running a 32b jvm via some wrapper utility?

The heap size was fixed to 512m for both JVMs, so I don't think memory/GC issues come into play here. But your points about 32bit/x86 emulation and different math instruction sets sound very plausible. Thanks for the ideas.

– Chris B Feb 9 at 0:49 @Chris I see you selected my answer. Care to share which point it ended up being? – KitsuneYMG Feb 10 at 17:29 To be honest, I'm still not sure.

Being a DB, the application is not really that math-heavy (in particular very few floating point calculations), so I think the 32bit JVM slowdown is most likely due to emulation. As you suggested, this emulation would be either on the OS side, running the JVM in a "32bit mode", or on the CPU side, emulating x86 instructions in microcode. Currently we don't have the hardware available to try the benchmark on equivalent hardware and a 32bit OS and/or CPU, so I can't confirm this.

– Chris B Feb 14 at 1:44.

From: oracle.com/technetwork/java/hotspotfaq-1... "Generally, the benefits of being able to address larger amounts of memory come with a small performance loss in 64-bit VMs versus running the same application on a 32-bit VM. This is due to the fact that every native pointer in the system takes up 8 bytes instead of 4. The loading of this extra data has an impact on memory usage which translates to slightly slower execution depending on how many pointers get loaded during the execution of your Java program.

The good news is that with AMD64 and EM64T platforms running in 64-bit mode, the Java VM gets some additional registers which it can use to generate more efficient native instruction sequences. These extra registers increase performance to the point where there is often no performance loss at all when comparing 32 to 64-bit execution speed. 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.

My best guess, based on a quick google for 32- vs 64-bit performance charts, is that 64 bit I/O is more efficient. I suppose you do a lot of I/O... If memcpy is involved when moving the data, it's probably more efficient to copy longs than ints.

That's interesting, I've never heard of 64bit I/O being more efficient, although I guess it makes sense. I'll try and google some hard data on that. – Chris B Feb 9 at 0:50 Could you share the link to the charts, please?Thanks.

– rodion Feb 9 at 1:51.

Realize that the 64-bit JVM is not magic pixie dust that makes Java apps go faster. The 64-bit JVM allows heaps >> 4 GB and, as such, only makes sense for applications which can take advantage of huge memory on systems which have it. Generally there is either a slight improvement (due to certain hardware optimizations on certain platforms) or minor degradation (due to increased pointer size).

Generally speaking there will be a need for fewer GC's -- but when they do occur they will likely be longer. In memory databases or search engines that can use the increased memory for caching objects and thus avoid IPC or disk accesses will see the biggest application level improvements. In addition a 64-bit JVM will also allow you to run many, many more threads than a 32-bit one, because there's more address space for things like thread stacks, etc.The maximum number of threads generally for a 32-bit JVM is ~1000but ~100000 threads with a 64-bit JVM.

Some drawbacks though: Additional issues with the 64-bit JVM are that certain client oriented features like Java Plug-in and Java Web Start are not supported. Also any native code would also need to be compatible (e.g. JNI for things like Type II JDBC drivers). This is a bonus for pure-Java developers as pure apps should just run out of the box.

More on this Thread at Java.net.

The 64-bit instruction set has 8 more registers, this should make the code faster overall. But, since processsors nowaday mostly wait for memory or disk, I suppose that either the memory subsystem or the disk i/o might be more efficient in 64-bit mode.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.