On Thu, Nov 27, 2008 at 8:23 PM, Jeremy Huntwork <[EMAIL PROTECTED]> 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: > > http://forums.amd.com/devblog/blogpost.cfm?threadid=93648&catid=317 > > 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 64-bit Linux. 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 standard. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
