tomcat-users mailing list archives

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