tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Anecito <adanec...@yahoo.com>
Subject Re: [OT] IIS7/isapi/tomcat performance
Date Tue, 01 Mar 2011 23:27:49 GMT
I believe the effect of compression is relative. In other words for a big 
program with lots of 64-bit pointers and 64-bit longs it is helps but for small 
programs it does not.

I would hope the full 64-bit data bus would be used. So you thing 32-pins on the 
processor are not used when running a 32-bit process? I am not saying you are 
not correct but I will check into it since I am curious and let you know what I 
find.

I have never mentioned byte code as pointers all my referneces are to executable 
code or what the processor actually runs.

Regards,
-Tony


 


----- Original Message ----
From: Christopher Schultz <chris@christopherschultz.net>
To: Tomcat Users List <users@tomcat.apache.org>
Sent: Tue, March 1, 2011 3:00:53 PM
Subject: Re: [OT] IIS7/isapi/tomcat performance

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

Tony,

On 3/1/2011 4:19 PM, Tony Anecito wrote:
> I guess you have not read my last email yet. I think of it as putting two  
> 32-bit pieces of info on a 64-bit data bus whereas for two 64-bit pieces of  
> information it takes two fetches or twice as long on the same hardware.

Are you saying that a 32-bit JVM running on a 64-bit machine somehow
utilizes the 64-bit bus? Malarkey. Perhaps the CPU as part of its
instruction re-ordering can do this, but I seriously doubt that a 32-bit
process on a 64-bit CPU gains a performance boost over that same 32-bit
process running on a 32-bit CPU (which is what the above would imply).

> As for compressing the pointers all I read is it improves response time

I can't believe that for a second. It actually slows things down. The
only reason to compress pointers is so that your heap size doesn't
roughly double when switching to 64-bit. The problem is that while the
transition from 32-bit to 64-bit architecture now allows many orders of
magnitude more memory to be accessed by each process (this is especially
important for Java heaps), the amount of memory installed in servers has
not really changed. 5 years ago, it wasn't uncommon for a 32-bit server
to have 32GiB of memory. These days, a similar 64-bit server might still
only have 32GiB of memory.

> so that 
> maybe running on 64-bit java the program is only 1% slower. I am assuming the 
> pointers are compressed after the first pass or even before the byte code is 
> run.

The pointers are compressed as the objects (really the references to
them) are created. The problem is that they must be uncompressed for
every dereference. It has nothing to do with the bytecode.

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

iEYEARECAAYFAk1tbJUACgkQ9CaO5/Lv0PBZ3ACgrVFqcPNcIe+P3U1HW3QzRXpS
L3oAnj82GTkXoQcOwxYskRLXWwsrFTcn
=w2cy
-----END PGP SIGNATURE-----

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


      

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


Mime
View raw message