[wellylug] Java 32 Bit/ Java 64 Bit Performance

[Daniel Pittman]

"Gerald.Roehrbein" <Gerald.Roehrbein at oraforecast.com> writes:

> that's a real world application written by a third party company.

Ouch.

> I was asked to analyze the reasons for the bad performance because my
> client and the developer thought the reason is Oracle because in their
> development environment the software performs much better in a client
> server environment with less and smaller CPU's, less network bandwidth
> between client and server and less IO performance at database level.
>
> The only reason I found was the difference between a full 32 Bit
> driven environment and the 64/32 Bit mixed environment.

*nod*

> I agree that the developer should change his programming strategies.
> They use dynamic arrays but they use container class libraries they
> developed in the past which could not not be changed easily.
>
> To have a full benchmark would allow to show the differences in detail
> and this would be better as to use a self made benchmark software.

Well, the official word from sun is that:

1. Only the "server" HotSpot Compiler is available with the 64-bit data
   model; I bet the vendor only uses the "client" HotSpot, which is
   faster[1] but less optimizing.

2. On amd64 vs ia32 you should see between a zero and a fifteen percent
   loss of performance, depending on the volume of pointers used.[2]

3. The default heap is 30 percent larger with the 64-bit model, to
   account for extra pointer overheads … but if you tune the heap
   manually and don't account for that you have increased memory
   pressure on the 64-bit version.

http://java.sun.com/docs/hotspot/HotSpotFAQ.html#64bit_performance

They also suggest some GC / heap tuning options in there.


I am still surprised that the JVM can have such a high cost from the
increase in pointer size, but presumably either the language
architecture makes it harder to take full advantage of the better
instruction and register set, or Java is pointer-heavy.[3]

Regards,
        Daniel

Footnotes: 
[1]  As in, it is a faster compiler at the cost of generating slower code.

[2]  This estimate seems quite a lot higher than it should be, to me,
     since native code (eg: C, etc) usually hits the zero percent side
     thanks to the other improvements.

[3]  This later woudln't surprise me, acutally; their standard library
     was clearly designed without thought to garbage generation,
     compared to more mature GC languages, so a design that was also
     pointer heavy is quite concievable.