The value of 64-bit vs 32-bit

Bryan Kadzban bryan at
Thu Nov 27 19:00:28 PST 2008

On Thu, Nov 27, 2008 at 09:23:41PM -0500, Jeremy Huntwork wrote:
> * Any comments on the details provided in the above article, 
> specifically in how that might relate to LFS?

Other than "that 3GB number is only applicable to Windows anyway", not
really.  :-P

> * If you were to benchmark 32-bit vs 64-bit on an LFS system, what would 
> your tests include?

I wouldn't bother benchmarking it.  Every single time that a bit width
increase has come along so far, it has eventually won out (except Itanium,
which came along too early and without enough attention paid to having
some sort of backward compatibility).  I don't think it's a question of
whether people should use 64-bit; I think it's a question of when they
will eventually move to it en masse.

Yes, on a current CPU, running 32-bit code is almost as fast as running
64-bit code.  But if it was a lot slower, people would complain that
their current programs ran slower, and you'd get another Itanium.  The
386 ran in real mode much faster than an 8086, as well, and at a similar
speed as it ran in 32-bit mode.  (At least, as far as clock rate goes;
there was overhead due to paging and segmentation.)  But nobody said
"you should keep running your 16-bit code", though; the fact that it
ran faster was one of the reasons Intel started selling a lot of 386s to
some people.)

Of course, if you have to choose between the two bit widths (i.e. if we
don't support multilib -- and I realize that would be a lot of work!),
it may still make sense to go with 32-bit, given the huge set of
programs already written out there.  But if you can run both, I see no
reason not to.

More information about the lfs-dev mailing list