Also, I have not programmed in assembly language or in hexadecimal  for some 
time but I would hope that for a 32-bit java process running on a 64-bit 
processor I would fetch a 32-bit pointer and maybe a 32-bit long on a 64-bit 
data bus. Remember we are talking about pointers in code coming into the 
processor via the data bus.

Interesting enough for AIX and Linux a long is 64bit for 64-bit java versus 
32-bit for 64-bit windows. So it looks like for Linux it would be slower than 
windows.
See: 
http://public.dhe.ibm.com/software/dw/jdk/64bitporting/64BitJavaPortingGuide.pdf

Bottom line on how much worse things get is based upon how many pointers and 
longs are used for 64-bit java that are used.

Regards,
-Tony



----- Original Message ----
From: Tony Anecito <adanec...@yahoo.com>
To: Tomcat Users List <users@tomcat.apache.org>
Sent: Tue, March 1, 2011 12:44:37 PM
Subject: Re: [OT] IIS7/isapi/tomcat performance

Hi Chris,

The performance degregation for 64 bit versus 32 bit has been the subject of 
much concern in the java community.

Here is the number I mentioned straight from Oracle itself:
http://www.oracle.com/technetwork/java/hotspotfaq-138619.html

What are the performance characteristics of 64-bit versus 32-bit VMs? 
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.   




If you google using the keywords: java 64-bit vs 32-bit performance
You will find alot of discussion about this.

Regards,
-Tony


----- Original Message ----
From: Christopher Schultz <ch...@christopherschultz.net>
To: Tomcat Users List <users@tomcat.apache.org>
Sent: Tue, March 1, 2011 8:29:11 AM
Subject: Re: [OT] IIS7/isapi/tomcat performance

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tony,

On 2/28/2011 2:57 PM, Tony Anecito wrote:
> Since the memory pointers are larger you may need to increase your heap size 
>but 
>
> you can compress the address pointers.

+1

> Also, if you use JNI and it is 32-bit then you will have unexpected issues 
> same 
>
>
> thing with any native libs your try to use.

+1

> Generally it will be up to 20% slower due to the pointers.

Can you explain that claim? Unless the OP is using compressed pointers
(which will require a decode in order to dereference), why would the
performance drop when using 64-bit pointers instead of 32-bit pointers.
Presumably, the CPU has 64-bit (or bigger) registers and can handle
64-bit numbers just as fast as 32-bit numbers. Or do modern CPUs run in
g a32-bit mode where the hardware doesn't bother to add-out to the 33+ bits?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1tEMcACgkQ9CaO5/Lv0PBa8ACgmRjggPsYHma8tShCNK2WfOJd
Qv8AoJ0KGEVwKQRDfSvwAvoF2Is5oHoW
=Anih
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to