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 <ch...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
