| |||||||||||
x86-64 distros needn't cripple themselves to support 32-bit.x86-64 distros needn't cripple themselves to support 32-bit.Posted Jun 13, 2004 16:21 UTC (Sun) by JoeBuck (subscriber, #2330)In reply to: x86-64 distros needn't cripple themselves to support 32-bit. by ncm Parent article: Debian x86_64 port ready
The decision they made lets Red Hat and SuSE on x86_64 run 32-bit LSB-compatible applications unchanged. The /lib64 will look like a historical artifact a few years from now, yes, but only developers (actually only a subset of developers) will be exposed to it. LSB should be thinking of a transition plan. Maybe specify /lib32, which might be a symbolic link. It will still be some time before 64-bit becomes a clear win for apps that don't need the address space: if you have an app that can fit in 32 bits, and its resident set size comes close to your physical memory size, the 64-bit version will page and swap and the 32-bit version won't. This isn't like the 16-32 transition, where people were fighting with overlays and other horrific schemes for years before 32 bits freed them of it.
(Log in to post comments)
x86-64 distros needn't cripple themselves to support 32-bit. Posted Jun 13, 2004 17:06 UTC (Sun) by loening (subscriber, #174) [Link] 64 bit is a win today even for apps that don't need it, due to the extra registers that are accessible to applications compiled as x86_64 apps.Your example of a 32 bit program fitting in physical memory, while the 64 bit version not fitting, is exceedingly unlikely. Remember, the size of data hasn't changed (which is what consumes most of memory), or even the size of instructions, only the size of pointers has doubled (correct me if I'm wrong on this). What could more likely happen is a 32bit version of a program fits in the CPU cache, while the 64bit is larger, so in some instances, the 32 bit application would be faster. But as the above poster said, 64bit is on average a 8% gain.
32-bit/64-bit performance comparison Posted Jun 13, 2004 18:15 UTC (Sun) by stevenj (subscriber, #421) [Link] For an example performance comparison (using gcc 3.3 on a 2GHz Opteron) benchmarking 32-bit and 64-bit performance of a few dozen real-world scientific codes (FFT implementations), see:The 32-bit and 64-bit numbers are on separate pages, since this benchmark was intended for comparing codes and not architectures, so interpretation is up to you. Some of the codes do seem to be markedly faster in 64-bit mode, although it's not clear whether this is just random gcc brokenness.
x86-64 distros needn't cripple themselves to support 32-bit. Posted Jun 14, 2004 4:01 UTC (Mon) by JoeBuck (subscriber, #2330) [Link] Actually, the case of a 32-bit app fitting in physical memory, while 64-bit doesn't, is quite common, for any app where the storage representation is dominated by pointers. Don't forget that today, people are squeezing hard to get their apps to barely fit in the 32-bit address space, so there are a lot of people right up near the boundary (particularly in chip design). There are various tricks to reduce the memory penalty for 64-bit, like trying to replace pointers with integer offsets where possible (to be able to address 2**32 words on a 64-bit machine).
x86-64 distros needn't cripple themselves to support 32-bit. Posted Jun 14, 2004 9:09 UTC (Mon) by joib (guest, #8541) [Link] Actually, the case of a 32-bit app fitting in physical memory, while 64-bit doesn't, is quite common, for any app where the storage representation is dominated by pointers.I read somewhere that on average, apps compiled as 64-bit tend to use 20 % more memory than when compiled as a 32-bit app. Don't forget that today, people are squeezing hard to get their apps to barely fit in the 32-bit address space, so there are a lot of people right up near the boundary (particularly in chip design). Yes, but as you certainly are aware, with 64-bit addressing we don't have to worry about the boundary (for the foreseeable future, at least). Using a large part of the address space is a nightmare anyway. With Linux, to use more than 1 GB you have to enable highmem support, with a small performance penalty. That gets you 3 GB for apps, if you want the full 4 GB you can use the 4g/4g patch, with an even greater performance penalty (especially if the app uses lots of syscalls). And the closer to the limit you get, the more you have to worry about stuff like suitable library offsets etc. With 64-bit addressing all those problems disappear. While you may hit the limit where you need to buy an extra stick of memory sooner with 64 bits than with 32, if you can afford the license for one of those commercial EDA packages as well as the engineer to use it, I'm pretty sure you can afford a couple of extra GB as well. Speaking of performance, the 8 % advantage mentioned above for 64 bit vs. 32 bit, seems to be for a lowmem 32 bit configuration. Comparing 64-bit with 4g/4g could give a significanly bigger advantage to the 64-bit version. There are various tricks to reduce the memory penalty for 64-bit, like trying to replace pointers with integer offsets where possible (to be able to address 2**32 words on a 64-bit machine). Uh oh, and I thought that the world has enought problems writing reliable and portable software as it is... ;-)
Why the band-aid? Posted Jun 14, 2004 2:42 UTC (Mon) by Ross (subscriber, #4065) [Link] There's a problem. It has come up more than one in practice, and evenmore often in theory. Why not solve it the right way? Either libraries should have the arch as part of the filename, there So you could have one of these: a) /lib/libc-N.N.N-arch.so This would be nice for changes which didn't involve word-size changes. Is this overdesigned, non-Unix-like, too big of a change, or what? It
Urr.. nevermind Posted Jun 14, 2004 3:48 UTC (Mon) by Ross (subscriber, #4065) [Link] I just read the comments about multiarch below. Needless to say I'mhappy with the planned changes.
|
|||||||||||