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 Thu, 03 Mar 2011 05:48:59 GMT
On the wiki Java long is 64-bits not sure what a Long is. So IBM is thinking 
C,C++ a long is 32bits which is what the paper meant.

So I as wrong.

Regards,
-Tony



----- Original Message ----
From: Tony Anecito <adanecito@yahoo.com>
To: Tomcat Users List <users@tomcat.apache.org>
Sent: Wed, March 2, 2011 9:15:09 PM
Subject: Re: [OT] IIS7/isapi/tomcat performance

Actually according to the IBM porting guide longs are different byte lengths 
depending upon what frame of reference they are speaking to.
On page 4 of the following port guide:

http://public.dhe.ibm.com/software/dw/jdk/64bitporting/64BitJavaPortingGuide.pdf

It states:For Windows, on 32-bit systems, integers, longs and pointers are all 
32-bits. On 64-bit systems, integers and
longs remain 32-bits, but pointers become 64-bits and long longs are 
64-bits.integers remain 32-bits and longs and pointers become 64-bits.
I could have interpreted this wrong but from a OS standpoint native code this is 

what they said. Now if the byte code is transalated to native code (which it 
must be to run). This would explain why Windows might seem to run faster than 
Linux for 64-bit.
 
Regarding bus usage I agree with Chuck's explanation about usage that the 
processors and I said so in a previous message.
 
Regards,
-Tony



----- Original Message ----
From: Christopher Schultz <chris@christopherschultz.net>
To: Tomcat Users List <users@tomcat.apache.org>
Sent: Wed, March 2, 2011 7:12:43 PM
Subject: Re: [OT] IIS7/isapi/tomcat performance

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

Tony,

On 3/1/2011 6:27 PM, Tony Anecito wrote:
> 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.

A long in Java is always 64 bits. Those /will/ be faster on a 64-bit
architecture. The only reason any of this is a problem is because
pointers (somewhat) unexpectedly double in size when moving from a
32-bit to a 64-bit platform. If you were running fine in a 128MiB heap
on a 32-bit machine, you may well have to increase your heap size on a
64-bit machine just to store the exact same set of objects.

> I would hope the full 64-bit data bus would be used. So you think 32-pins on 
>the 
>
> processor are not used when running a 32-bit process?

It depends upon exactly what the processor id doing. Those chips with
bundled x86 cores will use the x86 core (which is /only/ 32-bit, so
there's no option for 64-bit operations). Those chips which have only
x86-64 chips will either use 64 bits to manipulate 32-bit data (and
effectively "waste" the 32 most significant bits) or wave their hands
wildly and achieve some sort of miracle where 32-bit processes run twice
as fast because of a wider word size.

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

iEYEARECAAYFAk1u+RsACgkQ9CaO5/Lv0PCXegCfYWZr5Z8gOpHLH4g0FM3aJE5Z
ovEAn02zREkR5mqq1wX4dagQAq9MvACz
=v55r
-----END PGP SIGNATURE-----

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

For AIX and Linux, on 32-bit systems, integers, longs and pointers are all 
32-bits. On 64-bit systems, 




---------------------------------------------------------------------
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