[ubuntu-us-ut] 64-bit vs 32-bit (Was: Re: 10.04 CD shipment ordered)

[Aaron Toponce]

On 04/07/2010 09:53 AM, Christer Edwards wrote:
> On Wed, Apr 7, 2010 at 9:33 AM, Charles Curley
> <charlescurley at charlescurley.com> wrote:
>> On Wed, 7 Apr 2010 09:10:42 -0600
>> Aaron Toponce <aaron.toponce at gmail.com> wrote:
>>
>>> It's rather annoying they've stopped shipping 64-bit. I understand the
>>> reasoning of increased costs, but at the same time, they're hindering
>>> the progress of 64-bit penetration in the market. Of course, then
>>> again, Linux only has about 2% on the desktop, so where's the fire? :)
>>
>> Perhaps the idea is that if you have need of 64 bit Linux you have
>> pipes fat enough to haul in the ISO and roll your own. That may also
>> explain the two week delay.
> 
> I'd say it is as simple as 32bit will run on either hardware whereas 64bit wont.
> 
> I still don't bother with 64bit except on servers that need it. If you
> don't have 4G+, don't bother.

I'm going to pick on you a little Christer, because I think you should
know better. There is so much more to 64-bit vs. 32-bit argument than
just having 4+ GB of RAM. Really, the 32-bit PAE kernel can address 64
GB of RAM, so why even bother if RAM is the show-stopper? Because there
is so much more 64-bit than physical RAM sticks.

Here's why you should be running a 64-bit operating system if you have
64-bit hardware:

First, regarding RAM, 64-bit is an improvement, even if you have 2GB of
install RAM, because the *addressable* memory is so much greater.
Addressable RAM is important for the kernel when doing memory mapped
file I/O, which is quite common. With the 32-bit kernel, you have to
split the addressable space between the kernel and userspace (regardless
of how much RAM is physically installed). Historically, this was a 3:1
split, which is still the most common. You could also do a 2:2 or 4:4,
but the latter requires some hacks that cause performance degradation.

Continuing on with RAM, no matter how much you have installed, or if you
have PAE on your CPU, no process can address more than 3GB on a 3:1
split, 4GB max, if you're doing 4:4. So, if you have 3GB or more RAM in
your system, the only way to fully utilize it for any application on the
system is to go 64-bit.

Going even further with RAM, 64-bit kernel can physically support,
currently, 1TB RAM sticks, which the ability to be extended to 4PB of
RAM sticks.

Second, there are no memory split issues with a 64-bit kernel.
Currently, I believe the 64-bit Linux kernel can address something like
17 petabytes, which is still a far cry from the theoretical maximum
(IIRC, it's 16 exabytes!). So, because there are no splits, this means a
single 64-bit process can access more addressable memory than a 32-bit
process on the same system with the same amount of RAM.

Thirdly, and for me the most important, is the increased width on the
bus. I've made this analogy before, so you might be familiar with it,
but consider for a moment an 8-lane highway. Four lanes traveling south,
four lanes traveling north. What happens when the lanes fill to
capacity, and you still need to add cars to the road? Traffic jam. But
what if you had a 16-lane highway, with 8 lanes going north and 8 lanes
going south? You could increase that capacity! So increasing the bus by
*twice* (32-bit to 64-bit) means pushing more data between the CPU and
the RAM, which means getting more work done faster.

Now, what about a 32-bit system on 64-bit hardware? You'll never see the
capacity of the bus. You might never experience a traffic jam, but a
64-bit operating system would be able to push more data than a 32-bit
operating system, which means performance increases.

Fourth, and equally important, is increasing the space for mmap()'d
files due to the vastly increased addressable memory space. Because UNIX
and Linux are historically virtual memory systems, mmap() creates a
physical mapping of the file in the virtual address space, whether it be
in swap, RAM, CPU cache, disk cache, etc. More on mmap() can be found in
section 2 of the mmap manual on any Linux system, so I won't bother
rehashing the technicalities of mmap() here. Suffice it to say, a 64-bit
kernel can address a *lot* more virtual address space than 32-bit, which
means a *lot* more breathing room on file mapping. Current 64-bit
architectures can address 256TB of virtual address space, versus the 4GB
of virtual address space on 32-bit systems (remember that virtual
address space includes a lot more than just RAM).

A side benefit of a 64-bit kernel is stack space. With a 4k kernel (like
what Debian and Ubuntu use) on 32-bit, you run out of stack space in
deeply nested calls in the kernel. For example, if you use XFS on top of
LVM, and then share it over NFS, you will get a kernel oops on 32-bit
kernels. But, with 64-bit, you have a *lot* more stack space, and in
this scenario, you can safely and reliably use XFS with LVM over NFS.

These main advantages of a 64-bit kernel over a 32-bit kernel are
significant enough to produce reliable performance improvements on even
very mundane tasks. Think about it: more addressable RAM, increased bus
width, more breathing room on virtual memory, no kernel:user splits,
larger stack space. It's a complete win/win to run a 64-bit system on
64-bit hardware.

Now, the drawbacks. It's not all peaches and cream. The biggest drawback
to 64-bit, is the lack of a 64-bit flash browser plugin from Adobe. For
the desktop, that is. Right there, that hinders 64-bit adoption on the
desktop rather quickly, which may be a big reason why Canonical isn't
bothering to ship 64-bit pressed CDs, and why Microsoft isn't really
pushing their 64-bit Windows operating systems either.

Another problem is the increased size of a 64-bit binary versus a 32-bit
one. On top of the larger binary, 64-bit processes typically have higher
memory consumptions due to larger data structures. My experience has
shown that the range for additional memory consumption is around 2-5%,
compared to 32-bit.

However, due to the x86_64 architecture, you have the capability to run
32-bit applications on a 64-bit operating system. Which means, if there
is some "critical" application (like flash) that isn't compiled for a
64-bit arch, no big deal. Grab the 32-bit version, and execute away.

So, really, there's no reason to NOT run a 64-bit operating system on
64-bit hardware. The performance and reliability benefits far outweigh
the few drawbacks that I've mentioned above. In the GNU/Linux world, I
would say with confidence that 99% of upstream applications with source
available have been compiled for 64-bit as well as 32-bit. I've been
running 64-bit exclusively now, for almost 3 years, and I have yet to
run into an application where source was available that is not compiled
for the 64-bit architecture.

Conclusion: it's just silly to say "unless you have 4+ GB RAM, there is
no reason to run 64-bit". If you have the hardware, you should take
advantage of it.

-- 
. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-us-ut/attachments/20100407/68043b0d/attachment.pgp