Re: [OT] Followup on 32-bit versus 64-bit performance discussion(s)
On Tue, Mar 15, 2011 at 4:20 AM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: Leon Rosenberg [mailto:rosenberg.l...@gmail.com] Subject: Re: [OT] Followup on 32-bit versus 64-bit performance discussion(s) I'm sorry, I probably missed something, but why should 64 bit app on 64 bit os on 64 bit cpu be slower as 32 bit analog? Because all the data items are bigger, or have unused slack space associated with them, in a 64-bit JVM.  Consequently, the number of actually useful bits transferred between the CPU scheduler, the operand caches, and main memory is less per cycle. So a 64bit cpu has a 32bit mode, or how would a 32bit OS shrink the transmit size? I mean the registers stay the same? Leon  - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - 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
Re: [OT] Followup on 32-bit versus 64-bit performance discussion(s)
On 15 March 2011 07:36, Leon Rosenberg rosenberg.l...@gmail.com wrote: So a 64bit cpu has a 32bit mode, or how would a 32bit OS shrink the transmit size? I mean the registers stay the same? Frequently, the bottleneck with realistic loads is access to main memory (or, not quite equivalently, on-die cache size). Assuming you have some locality of reference (adjacent instructions tend to be executed together, adjacent data items tend to be used together) then transferring 128 bits from main memory to cache is somewhat more likely to get you more useful bits of data in 4x32 bit items than in 2x64 bit items. - Peter
RE: [OT] Followup on 32-bit versus 64-bit performance discussion(s)
From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: [OT] Followup on 32-bit versus 64-bit performance discussion(s) A 32-bit process, using 32-bit pointers, will enjoy a 2x speedup for those types of data. Also, a Java int, when allocated on the stack, must take up the same number of bits as a pointer. Consequently, in a 64-bit JVM the stack slots are bigger for primitive values, and have unused bits in them for everything except pointers. (Allocations on the heap do not include the unused bits, at least in current JVM versions.) - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: [OT] Followup on 32-bit versus 64-bit performance discussion(s)
On 15 March 2011 13:02, Caldarale, Charles R chuck.caldar...@unisys.comwrote: Also, a Java int, when allocated on the stack, must take up the same number of bits as a pointer. That's an interesting space/time trade-off (I presume it's to prevent excess arithmetic on stack value accesses). I wonder whether it's still a good trade-off on (say) a modern Intel architecture? - Peter
RE: [OT] Followup on 32-bit versus 64-bit performance discussion(s)
From: peter.crowth...@googlemail.com [mailto:peter.crowth...@googlemail.com] On Behalf Of Peter Crowther Subject: Re: [OT] Followup on 32-bit versus 64-bit performance discussion(s) Also, a Java int, when allocated on the stack, must take up the same number of bits as a pointer. That's an interesting space/time trade-off (I presume it's to prevent excess arithmetic on stack value accesses). It's a requirement of the JVM (not language) spec so that the various stack manipulation byte codes can be independent of the type of data on the stack. A pointer, int, or float must take one stack slot, while a long or double must take two - regardless of the size of a slot. A modern JIT is certainly aware of the type of data in each stack slot, but interpreters aren't, so it's likely to stay that way. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Followup on 32-bit versus 64-bit performance discussion(s)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 3/15/2011 9:02 AM, Caldarale, Charles R wrote: From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: [OT] Followup on 32-bit versus 64-bit performance discussion(s) A 32-bit process, using 32-bit pointers, will enjoy a 2x speedup for those types of data. Also, a Java int, when allocated on the stack, must take up the same number of bits as a pointer. Consequently, in a 64-bit JVM the stack slots are bigger for primitive values, and have unused bits in them for everything except pointers. (Allocations on the heap do not include the unused bits, at least in current JVM versions.) A Java int is defined to be 32-bits. Why would it have to be word-length on the stack? Is that documented anywhere, or does it just end up being the reality of the JVM implementations? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1/fE8ACgkQ9CaO5/Lv0PCkyQCfUsPTmc/UwTGPv/rREr2XJqrv 2ooAoIkGAsLrAFpHilwvGzm1FgjGvvpD =ovb8 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Followup on 32-bit versus 64-bit performance discussion(s)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 3/14/2011 11:20 PM, Caldarale, Charles R wrote: From: Leon Rosenberg [mailto:rosenberg.l...@gmail.com] Subject: Re: [OT] Followup on 32-bit versus 64-bit performance discussion(s) I'm sorry, I probably missed something, but why should 64 bit app on 64 bit os on 64 bit cpu be slower as 32 bit analog? Because all the data items are bigger, or have unused slack space associated with them, in a 64-bit JVM. Consequently, the number of actually useful bits transferred between the CPU scheduler, the operand caches, and main memory is less per cycle. So, back to the original question: will a 32-bit JVM on a 64-bit OS give me a bigger heap potential than a 32-bit JVM on a 32-bit OS? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1/fL4ACgkQ9CaO5/Lv0PBnZACfUf5zX6ekYrHMi8euKtEQy9S9 GDAAn06nv9iAr33LLeUs380J8Fd8/At9 =O1xj -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT] Followup on 32-bit versus 64-bit performance discussion(s)
From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: [OT] Followup on 32-bit versus 64-bit performance discussion(s) So, back to the original question: will a 32-bit JVM on a 64-bit OS give me a bigger heap potential than a 32-bit JVM on a 32-bit OS? Depends entirely on the how the OS chooses to handle the 32-bit process virtual space. If the OS continues to maintain the 2 or 3 GiB boundary, your maximum heap isn't going to improve. If the OS allows all 4 GiB to be used by the process, then the heap could be larger. I haven't experimented to find out. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
RE: [OT] Followup on 32-bit versus 64-bit performance discussion(s)
From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: [OT] Followup on 32-bit versus 64-bit performance discussion(s) A Java int is defined to be 32-bits. Why would it have to be word-length on the stack? Is that documented anywhere, or does it just end up being the reality of the JVM implementations? It's in the JVM spec, as I stated: http://marc.info/?l=tomcat-userm=130019552201152w=2 - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: [OT] Followup on 32-bit versus 64-bit performance discussion(s)
On 3/14/2011 1:01 PM, Christopher Schultz wrote: ... We are going into a production upgrade cycle and I'd like to plan for the OS type: if we get no benefit from running a 64-bit OS then I won't bother installing one. If you're using windows server machines, Server 2008 R2 (and maybe Server 2008 original) is 64-bit only. Older windows server versions come in both, and Linux of course has a choice. D - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Followup on 32-bit versus 64-bit performance discussion(s)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David, On 3/14/2011 1:22 PM, David kerber wrote: On 3/14/2011 1:01 PM, Christopher Schultz wrote: ... We are going into a production upgrade cycle and I'd like to plan for the OS type: if we get no benefit from running a 64-bit OS then I won't bother installing one. If you're using windows server machines, Server 2008 R2 (and maybe Server 2008 original) is 64-bit only. Older windows server versions come in both, and Linux of course has a choice. I should have mentioned, we are in a Linux environment, so we have lots of options. ;) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1+UOgACgkQ9CaO5/Lv0PBWhgCfSVvpenkOypWknzJAOYZfYflb x+UAn15NpOmuizWKlo3hPTaOL5Rzzelt =B4k2 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Followup on 32-bit versus 64-bit performance discussion(s)
On 3/14/2011 1:31 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David, On 3/14/2011 1:22 PM, David kerber wrote: On 3/14/2011 1:01 PM, Christopher Schultz wrote: ... We are going into a production upgrade cycle and I'd like to plan for the OS type: if we get no benefit from running a 64-bit OS then I won't bother installing one. If you're using windows server machines, Server 2008 R2 (and maybe Server 2008 original) is 64-bit only. Older windows server versions come in both, and Linux of course has a choice. I should have mentioned, we are in a Linux environment, so we have lots of options. ;) Lucky you; I wish I could say the same... D - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Followup on 32-bit versus 64-bit performance discussion(s)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David, On 3/14/2011 1:36 PM, David kerber wrote: On 3/14/2011 1:31 PM, Christopher Schultz wrote: I should have mentioned, we are in a Linux environment, so we have lots of options. ;) Lucky you; I wish I could say the same... You should lobby to virtualize your infrastructure on top of some kind of Linux-based virtualization platform. Then you can still be running on Windows but also have some ... other options ;) I would suggest the other way around if you wanted to operate in a Linux environment, but if the idea is to improve stability, then running Linux on top of Windows isn't exactly recommended technique. I had always heard that Microsoft SQL Server was a really good RDBMS. It's just too bad it has to run on Windows. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1+VDYACgkQ9CaO5/Lv0PBD+wCfQBK7R2hi6tcsxYaIjNTMYQsR jlkAnijh8Tmk7JEX8GLsfzFkf/4qc8Ck =emTF -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Followup on 32-bit versus 64-bit performance discussion(s)
I'm sorry, I probably missed something, but why should 64 bit app on 64 bit os on 64 bit cpu be slower as 32 bit analog? regards Leon On Mon, Mar 14, 2011 at 6:45 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David, On 3/14/2011 1:36 PM, David kerber wrote: On 3/14/2011 1:31 PM, Christopher Schultz wrote: I should have mentioned, we are in a Linux environment, so we have lots of options. ;) Lucky you; I wish I could say the same... You should lobby to virtualize your infrastructure on top of some kind of Linux-based virtualization platform. Then you can still be running on Windows but also have some ... other options ;) I would suggest the other way around if you wanted to operate in a Linux environment, but if the idea is to improve stability, then running Linux on top of Windows isn't exactly recommended technique. I had always heard that Microsoft SQL Server was a really good RDBMS. It's just too bad it has to run on Windows. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1+VDYACgkQ9CaO5/Lv0PBD+wCfQBK7R2hi6tcsxYaIjNTMYQsR jlkAnijh8Tmk7JEX8GLsfzFkf/4qc8Ck =emTF -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
Re: [OT] Followup on 32-bit versus 64-bit performance discussion(s)
In general, it is technically possible for a 32-bit application to perform faster than a 64-bit application when running on a 64-bit CPU because of CPU memory cache behaviour. 64-bit memory addresses occupy more space within a single cache line and can result in added memory cache misses (cache lines filled more quickly) which require additional loads from real memory into CPU registers, effectively slowing down the performance of an application. Sent from my BlackBerry device -Original Message- From: Leon Rosenberg rosenberg.l...@gmail.com Date: Mon, 14 Mar 2011 20:33:21 To: Tomcat Users Listusers@tomcat.apache.org Reply-To: Tomcat Users List users@tomcat.apache.org Subject: Re: [OT] Followup on 32-bit versus 64-bit performance discussion(s) I'm sorry, I probably missed something, but why should 64 bit app on 64 bit os on 64 bit cpu be slower as 32 bit analog? regards Leon On Mon, Mar 14, 2011 at 6:45 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David, On 3/14/2011 1:36 PM, David kerber wrote: On 3/14/2011 1:31 PM, Christopher Schultz wrote: I should have mentioned, we are in a Linux environment, so we have lots of options. ;) Lucky you; I wish I could say the same... You should lobby to virtualize your infrastructure on top of some kind of Linux-based virtualization platform. Then you can still be running on Windows but also have some ... other options ;) I would suggest the other way around if you wanted to operate in a Linux environment, but if the idea is to improve stability, then running Linux on top of Windows isn't exactly recommended technique. I had always heard that Microsoft SQL Server was a really good RDBMS. It's just too bad it has to run on Windows. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1+VDYACgkQ9CaO5/Lv0PBD+wCfQBK7R2hi6tcsxYaIjNTMYQsR jlkAnijh8Tmk7JEX8GLsfzFkf/4qc8Ck =emTF -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
Re: [OT] Followup on 32-bit versus 64-bit performance discussion(s)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Justin, On 3/14/2011 3:45 PM, Justin Randall wrote: In general, it is technically possible for a 32-bit application to perform faster than a 64-bit application when running on a 64-bit CPU because of CPU memory cache behaviour. Also due to the amount of data that can be transferred at once across the data paths to the CPU: 64-bit pointers simply take up more bandwidth on those paths. A 32-bit process, using 32-bit pointers, will enjoy a 2x speedup for those types of data. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1+g+MACgkQ9CaO5/Lv0PB8DwCgqTO/v8DuSS4M8qKbAiGAMJch bVoAoIdFUL3MM0TqBOFxWZfMp/+9s8At =2ZPm -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Followup on 32-bit versus 64-bit performance discussion(s)
Indeed. It really makes you wonder why caches and pipelines weren't scaled more proportionally. At least we can appreciate better calling conventions. :) --Original Message-- From: Christopher Schultz To: Tomcat Users List ReplyTo: Tomcat Users List Subject: Re: [OT] Followup on 32-bit versus 64-bit performance discussion(s) Sent: Mar 14, 2011 17:08 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Justin, On 3/14/2011 3:45 PM, Justin Randall wrote: In general, it is technically possible for a 32-bit application to perform faster than a 64-bit application when running on a 64-bit CPU because of CPU memory cache behaviour. Also due to the amount of data that can be transferred at once across the data paths to the CPU: 64-bit pointers simply take up more bandwidth on those paths. A 32-bit process, using 32-bit pointers, will enjoy a 2x speedup for those types of data. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1+g+MACgkQ9CaO5/Lv0PB8DwCgqTO/v8DuSS4M8qKbAiGAMJch bVoAoIdFUL3MM0TqBOFxWZfMp/+9s8At =2ZPm -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Sent from my BlackBerry device
Re: [OT] Followup on 32-bit versus 64-bit performance discussion(s)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Justin, On 3/14/2011 5:44 PM, Justin Randall wrote: It really makes you wonder why caches and pipelines weren't scaled more proportionally. Not to mention memory sizes in general. We got a 2^32-fold increase in addressable memory. Great. Where is my 128YiB SODIMM chip? :p - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1+yPwACgkQ9CaO5/Lv0PAhsgCdHY3f9rQK0XMlubQGuzeqUGk8 WAEAn1i6E+quCSVoGHenIja18nLYdepz =QWHS -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT] Followup on 32-bit versus 64-bit performance discussion(s)
From: Leon Rosenberg [mailto:rosenberg.l...@gmail.com] Subject: Re: [OT] Followup on 32-bit versus 64-bit performance discussion(s) I'm sorry, I probably missed something, but why should 64 bit app on 64 bit os on 64 bit cpu be slower as 32 bit analog? Because all the data items are bigger, or have unused slack space associated with them, in a 64-bit JVM. Consequently, the number of actually useful bits transferred between the CPU scheduler, the operand caches, and main memory is less per cycle. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
