Kenneth Burgener wrote:
>
> 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)
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.
> 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.
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.
> 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.
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.
> 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.
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.
--
Florin Andrei
http://florin.myip.org/
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
