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. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
