I am curious what should be the benchmark for making the choice of switching from 32bit to 64bit Linux? I have a few assumptions below. Is my logic sound? (This is a follow up to the "Adding RAM" thread)
Assumptions:
1. 4GB Memory. The main benefit of 64bit mode is the ability to address more than 4GB of RAM. I assume that you use 64bit mode if you want to *efficiently* have more than 4GB of RAM, or intend to upgrade past 4GB in the foreseeable future. (I emphasize "efficiently" because PAE is an option, if you are desperate to keep 32bit mode with more RAM)
2. Overhead. It is my assumption that 64bit has more "overhead", being that the registers are now 64bits long, instead of 32bit, which would mean more bits to pass around the system. So if you have less than 4GB of RAM, 32bit mode would perform better than 64bit mode.
3. Compatibility. Linux has made incredible strides to make 64bit Linux very robust and compatible, but I still occasionally see binary applications/plugins/drivers that popup which are 32bit mode only. This is usually only a problem with Desktop systems that want bleeding edge, or not as well supported software.
4. Desktop vs Servers. Current "desktops" machines generally have around 2GB of RAM, or less. Current "server" machines generally have around 2GB of RAM, or more (much more). Because of the overhead (#2) and compatibility (#3) I would think that Desktops would benefit from using 32bit mode, and Servers would benefit from 64bit mode.
Is my logic sound?
Thanks, Kenneth
On Sun, 2008-12-07 at 23:06 -0700, Kenneth Burgener wrote:
Assumptions:
- 4GB Memory.
- Overhead.
- Compatibility.
- Desktop vs Servers.
Is my logic sound?
Number 1 is a bit off. But just a bit. Number 2 is solid. Number 3 is... mostly irrelevant with CentOS. Number 4 is not specific enough.
First, The 4GB limit. Yes, 64-bit allows the OS access to more than 4GB of *physical* memory. However, it *also* allows (64-bit) processes to access more than 4GB of *virtual* memory. This can be invaluable in applications that process a lot of data.
Second, compatibility. Upstream's use of multilib allows 32-bit applications to be run on a 64-bit system without much trouble. Plugins, specifically Firefox plugins, have the better part of a solution in the form of nspluginwrapper. Drivers not much can be done about; fortunately there aren't too many of those.
Third, desktop versus server. Let's ignore the 4GB limit discussed above while we examine this one. For PPC versus PPC64 your argument is valid. For IA-32 versus X86-64, you need to look at what the desktop will be used for. One of the benefits X86-64 gives you over IA-32 is more registers within the CPU. Operations involving registers are *much* faster than operations involving memory, allowing X86-64 apps to be up to about 15% faster than IA-32 in mathematical, scientific, or multimedia applications.
On Sun, Dec 7, 2008 at 11:02 PM, Ignacio Vazquez-Abrams ivazqueznet@gmail.com wrote:
On Sun, 2008-12-07 at 23:06 -0700, Kenneth Burgener wrote:
- 4GB Memory.
I'd like to add a note regarding the 4G/4G split issue. Unlike hugemem in CentOS/RHEL-4, the PAE kernel in CentOS/RHEL-5 does not provide 4GB per user process. In this regard, there is no hugemem-equivalent in CentOS/RHEL-5. This was mentioned in the upstream bugzilla [1]. In other words, applications that can take advantage of 4GB per process should benefit from the 64-bit.
There is a description in section 40.1 (kernel-PAE) of the CentOS online documentation:
"4GB/4GB split: 4GB of virtual address space for the kernel and almost 4GB for each user process on x86 systems"
This is incorrect and has been removed from the same page upstream. I filed a bug report regarding updating the CentOS lnline doc [2].
[1] https://bugzilla.redhat.com/show_bug.cgi?id=241314 [2] http://bugs.centos.org/view.php?id=3231
Akemi / toracat
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Kenneth Burgener Sent: Monday, December 08, 2008 7:06 AM To: CentOS mailing list Subject: [CentOS] Is 4GB memory the 64bit switch tipping point?
I am curious what should be the benchmark for making the choice of switching from 32bit to 64bit Linux? I have a few assumptions below. Is my logic sound? (This is a follow up to the "Adding RAM" thread)
4GB Memory.
Compatibility.
I've been mainly bitten by paragraphs 1 and 3 with respect to the server-side installations.
I opted to run the x86 PAE-kernel instead of going with the 64b-OS, on my Dell PE (which has 4GB RAM). This coincidentally also solved issue #3, the compatibility concerns (as in software). Most everything will run fine on 32b, be it server or desktop.
If you want to run really modern hardware you might have issues with either x86 or x64 OS:es. My Dell PE is a refurbished machine with a couple of years under the belt, so hardware incompatibilities shouldn't be a concern with eg CentOS 5.2. Software dittos is another matter though, especially if I'd opted with a x64 OS.
This goes for both CentOS/linux and in my case Windows as well. I admin both camps. Your own personal mileage may vary though, as you may run different hardware and software than I do, so generalizing may be a bit difficult IMHO and filled with gotchas' as it were.
HTH.
Kenneth Burgener wrote:
- 4GB Memory. The main benefit of 64bit mode is the ability to
address more than 4GB of RAM. I assume that you use 64bit mode if you want to *efficiently* have more than 4GB of RAM, or intend to upgrade past 4GB in the foreseeable future. (I emphasize "efficiently" because PAE is an option, if you are desperate to keep 32bit mode with more RAM)
As a general rule, at 4GB or more it's time to look at a 64 bit OS. Before that limit, maybe not so much.
But it depends on a lot of other factors.
Overall, I don't think the memory is the deciding factor in most cases.
- Overhead. It is my assumption that 64bit has more "overhead", being
that the registers are now 64bits long, instead of 32bit, which would mean more bits to pass around the system. So if you have less than 4GB of RAM, 32bit mode would perform better than 64bit mode.
That makes no sense to me. A lot of apps, if compiled natively on the 64 bit OS, actually offer better performance than the 32 bit builds running on a 32 bit OS. Case in point which I investigated recently, MythTV. I'm sure there are other examples.
This might happen because a lot of CPUs nowadays are really 64 bit architectures, with the 32 bit compatibility not quite such a central focus.
There might be performance issues with 32bit apps running on 64bit OS with compat libs and such, but I'm not sure about that, and it wouldn't be surprising anyway, considering it's a stopgap procedure.
- Compatibility. Linux has made incredible strides to make 64bit
Linux very robust and compatible, but I still occasionally see binary applications/plugins/drivers that popup which are 32bit mode only. This is usually only a problem with Desktop systems that want bleeding edge, or not as well supported software.
To me that was the biggest issue with 64 bit on the desktop. Also, on the server, if the major application is 32 bit, you tend to put it on a 32 bit OS and don't muck with mixed architectures, or else face support issues (nobody got fired for following the vendor's recommendations).
For the desktop only:
It looks like nowadays we're getting close to the comfort zone, or perhaps we're there already. There's a native 64 bit Flash plugin (still in beta), there's a 64 bit OpenJDK that includes a Java browser plugin. VMware and other virtual OS applications seem to work fine in mixed architecture environments. Even before, it was still possible to install 32 bit Flash and Java in a 32 bit browser on a 64 bit OS, or use ndispluginwrapper to combine mixed architectures, but those solutions were pretty ugly.
There might be some close-source apps which are still 32 bit only, e.g. Google Earth and such. These appear to work fine if you install the 32 bit compat libs on a 64 bit OS.
I haven't seen any issues with the closed source drivers that I use (but I don't use anything besides NVidia).
I'm not yet sure what happens with the WINE stuff on 64 bit. That's really the last remaining question mark for me.
Keep in mind, though, I don't use CentOS on the desktop. However, Linux is Linux, so the observations above should still be relevant. I recently installed the 32 bit edition of Ubuntu 8.10 on my desktops, but I'm seriously considering the 64 bit build for the upgrade to the next version, when it gets released next year.
- Desktop vs Servers. Current "desktops" machines generally have
around 2GB of RAM, or less. Current "server" machines generally have around 2GB of RAM, or more (much more). Because of the overhead (#2) and compatibility (#3) I would think that Desktops would benefit from using 32bit mode, and Servers would benefit from 64bit mode.
I've seen essentially no major issues with 64 bit on the servers. I've been using it for quite a while, whenever possible. In fact, 32 bit on the server nowadays seems like a last-resort fallback solution, in those rare cases when 64 bit really won't work (and even then it's due to a bug, or lazy vendors, or something like that).
For 64 bit on the desktop, see my comments on point #3 above.
So, in case it was not clear:
On the server, it's 64 bit by default except some rare (and now vanishing) cases when that won't work for some odd reason.
On the desktop, it's still 32 bit for me, but I'm probably too conservative. If you only use the stuff that's in the distro, then 64 bit on the desktop is OK.
On Mon, 8 Dec 2008, Florin Andrei wrote:
On the server, it's 64 bit by default except some rare (and now vanishing) cases when that won't work for some odd reason.
For servers, 32-bit installations are our norm in only two cases: Xen VMs, which in our environment tend to have limited memory, and 32-bit development machines. In the latter case, I don't want the developers to have to remember some chroot or odd gcc invocation to get 32-bit binaries.
On Mon, Dec 8, 2008 at 11:35 AM, Florin Andrei florin@andrei.myip.org wrote:
It looks like nowadays we're getting close to the comfort zone, or perhaps we're there already. There's a native 64 bit Flash plugin (still in beta), there's a 64 bit OpenJDK that includes a Java browser plugin. VMware and other virtual OS applications seem to work fine in mixed architecture environments. Even before, it was still possible to install 32 bit Flash and Java in a 32 bit browser on a 64 bit OS, or use ndispluginwrapper to combine mixed architectures, but those solutions were pretty ugly.
I think you meant nspluginwrapper - ndiswrapper is for Window$ drivers to run in Linux.
:-)
mhr
MHR wrote:
I think you meant nspluginwrapper - ndiswrapper is for Window$ drivers to run in Linux.
d'oh! brain segfault :)
On Sun, Dec 7, 2008 at 10:06 PM, Kenneth Burgener kenneth@mail1.ttak.org wrote:
I am curious what should be the benchmark for making the choice of switching from 32bit to 64bit Linux? I have a few assumptions below. Is my logic sound? (This is a follow up to the "Adding RAM" thread)
Assumptions:
- 4GB Memory. The main benefit of 64bit mode is the ability to
address more than 4GB of RAM.
...... Lots of other good responses but the critical tipping point after functionality is 'benchmark results' as noted in the opening paragraph. The next is data set size but with a little care in the code this is mostly not an issue (size of pipe is BIG) so as long as the kernel can address and manage all memory it is the rare application+data set that needs 64bit longs and pointers.
The point about benchmarking is critical when deciding 64bit .vs. 32 bit. Modern x86_64 processors can run both 32bit and 64bit applications, the key is that the processor register and instruction set is richer in 64bit mode which permits the compiler to do more for many but not all applications.
The ability of compilers to take advantage of the richer 64bit ABI can be massive. I have seen Fortran and C programs improve as much as +70%
The gcc family of compilers is much improved over gcc of 5 years ago. Specialty vendor compilers can still show important gains over gcc so kick the tires when ya can.
YMMV.
Later, mitch
-
Akemi Yagi -
Florin Andrei -
Ignacio Vazquez-Abrams -
Kenneth Burgener -
MHR -
NiftyClusters T Mitchell -
Paul Heinlein -
Sorin Srbu