CentOS - Dec 2008 - 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)

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:
> 
> 1.  4GB Memory.
> 2.  Overhead.
> 3.  Compatibility.
> 4.  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.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

PLEASE don't CC me; I'm already subscribed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.centos.org/pipermail/centos/attachments/20081208/676848d2/attachment-0003.sig>

>-----Original Message-----
>From: centos-bounces at centos.org [mailto:centos-bounces at 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)
>
>1.  4GB Memory.
>
>3.  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.
-- 
/Sorin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5126 bytes
Desc: not available
URL:
<http://lists.centos.org/pipermail/centos/attachments/20081208/648e9c28/attachment-0003.bin>

On Sun, Dec 7, 2008 at 11:02 PM, Ignacio Vazquez-Abrams
<ivazqueznet at gmail.com> wrote:
> On Sun, 2008-12-07 at 23:06 -0700, Kenneth Burgener wrote:
>>
>> 1.  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

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/

On Sun, Dec 7, 2008 at 10:06 PM, Kenneth Burgener
<kenneth at 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:
>
> 1.  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



-- 
        NiftyCluster
        T o m   M i t c h e l l