The value of 64-bit vs 32-bit
bruce.dubbs at gmail.com
Thu Nov 27 22:01:45 PST 2008
On Thu, Nov 27, 2008 at 8:23 PM, Jeremy Huntwork
<jhuntwork at linuxfromscratch.org> wrote:
I'm responding to the initial post, but I've read several responses
and implicitly am responding to those too.
> About a month or so ago I'd said I'd start looking into writing a
> section for LFS that deals with pros/cons of using full 64-bit
> libs/binaries in Linux, since LFS is considering adding in 64-bit support.
> I came across this article:
> and several other articles from people who at various times benchmarked
> performance with 32-bit vs 64-bit on the same hardware.
An interesting article. One thing to note is that a 5% or 10%
performance change is really negligible. A person needs to see at
least a 50% improvement to even notice. I think that's documented in
research, but I can't put my finger on it right now.
> Just two quick questions:
> * Any comments on the details provided in the above article,
> specifically in how that might relate to LFS?
The issue is compatibility vs speed. The speed improvements are not
significant for most applications. It's true that if you are going to
memory map a very large file, as in editing a movie, then the
increased address space would be quite useful. Other areas are when
physical ram exceeds 4G or very high accuracy calculations (e.g.
solving systems of differential equations) are needed, the increased
address space and register size is needed.
One commenter said that virtually everything except flash and grub
were 64 bit. I believe that flash is a very important application for
many users and until that becomes available, many users will reject
Compatibility of older hardware is also an issue. Many of the older
hardware drivers may have issues when trying to run in 64-bit mode.
I've heard of a lot of problems with things like wifi drivers in some
commercial 64 bit distros.
Building a multi-lib system will be much more complicated than a
32-bit system. For that reason alone, I wouldn't recommend that users
try it until they were successful in building a 32-bit LFS and a great
deal of 32-bit BLFS.
> * If you were to benchmark 32-bit vs 64-bit on an LFS system, what would
> your tests include?
For us, the easiest benchmark is compile times. We really don't have
the resources to benchmark real applications. In addition, many of
the "benchmarks" I see published are garbage -- frames / second of
some Windows game comes to mind.
As a side note to Bryan: The Itanium is still alive and kicking. It
was all over the place at the Supercomputer 2008 Conference in Austin
earlier this month.
The biggest 'Pro' to doing a 64-bit LFS is "Because we can, and we
like to experiment." I still feel for the vast majority of users, it
is not needed for every day use. There is a huge difference between
the jump from 16-bit processors to 32-bit processors and the next jump
from 32-bits to 64-bits. Remember that the numbers here are
exponents. Each increment represents doubling the address space and
the value a single entry can represent. 16 bits was clearly
unsatisfactory because a 64K byte address space just wasn't enough.
It's not clear that most users need more than 4G of address space.
Remember that the most common size of data is still the 8-bit char for
integer data and even the 80287 did floating point with an 80-bit
More information about the lfs-dev