[aklug] Re: 32 vs 64 bit

On Sun, 24 Oct 2010, Tim Gibney wrote:

> In a AKLUG meeting a few months ago I defended using 32-bit Linux as I found
> no need to bother with 64-bit.
>
> My opinion changed as I have a new 64-bit system here. ... my last system
> was 64-bit but had 2 gigs of ram so I didn't bother.
>
> 64-bit cpu's have extra registers which hold variables on the CPU rather
> than the ram. In addition, newer VM and MMX instructions speed up
> virtualization, data compression and multimedia. Everything from unzipping a
> folder, running tar, or creating mp3s is faster under 64 bit mode. If you
> run virtual box or VMWare to run Windows or other Linux guest operating
> systems then you will notice an even further speed boasts. On my system I
> can not even run a 64-bit guest Linux OS without Hyper-V enabled. Databases
> also use these extra CPU registers for common table IDs, columns, and rows.
> Unless you just browse the web with a netbook you will notice a difference
> under these tasks. I think in the future the CPU makers should focus on
> putting tons and tons of registers on the CPU itself which get rid of the
> ram bottleneck.
>
> I was hesitant earlier to use a 64-bit version of Linux due to bad flash and
> Java support but that problem is going away.

Just a cautionary note but performance for regular desktop computing really
isn't about 32 or 64-bit, it's about whether the software is optimized for
your processor. The perceived difference in performance is often more due
to 32-bit distros being compiled for generic x86 processors, while the
64-bit distros are compiled for more modern processors, and hence, take
advantage of the more modern features.

In fact, in some workloads compiling for 32-bits but optimized for your
target processor can be faster than the 64-bit version because they can use
the unused half of the 64 bit registers for additional near-line caching of
variables.

The reality is that some workloads benefit from being explicitly 64-bit
(those dealing with very large datasets, some computational workloads,
virtualization, etc.) but for the average desktop/office worker, it really
doesn't provide much benefit at all.

BTW, the RAM bottleneck (comparitively speaking) is continually being
addressed. In the old days it was about expanded L1/L2 cache on die. Some
even have L3 on die now, but the integration of independent memory
controllers, cross bar architectures, etc., are all aimed clearly at
reducing that.

:-) Not to be contrary, but bah! No one will *ever* need more than
8-bits... I'm going back to my den to live in the past...

         --Arthur Corliss
           Live Free or Die
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Mon Oct 25 00:32:37 2010