x86-64 distros need to support 32-bit [LWN.net]

x86-64 distros need to support 32-bit

Posted Jun 13, 2004 0:55 UTC (Sun) by JoeBuck (subscriber, #2330)
In reply to: Debian x86_64 port ready - details by alexperry
Parent article: Debian x86_64 port ready

Unfortunately, the shipping distros for x86-64, from SuSE and Red Hat, are mixed 32/64 bit, and these distros are already attracting considerable support for third party application developers (particularly in the electronic design automation industry, which is adopting Red Hat Enterprise 3.0 for the Opteron in a big way, as the cheapest source of 64-bit cycles, for the development of state-of-the-art chips that don't fit into a 32-bit address space; costs of RHEL licenses are negligible compared to costs for the EDA tools.

SuSE and Red Hat are shipping multilib'd distros (supporting both 32-bit and 64-bit binaries). They are shipping now; Debian is chasing. It's not a good idea for the chaser to be clearly inferior, and not supporting 32-bit means that you're inferior.

For many apps, 32-bit code will be faster on the Opteron than 64-bit (32-bit tuned code, that is, not the Debian i386 stuff). A competitive x86-64 distro needs to support both.

Now, perhaps it's possible for Debian to start out as 64-bit only and cleanly add the 32-bit stuff later. But until this is corrected, people with an Opteron box who aren't RMS-style purists will want to run SuSE or Fedora, since with Debian they won't be able to run any code that is only available as x86 binary code (video codecs, Wine, games, etc).

(Log in to post comments)

x86-64 distros needn't cripple themselves to support 32-bit.

Posted Jun 13, 2004 1:42 UTC (Sun) by ncm (subscriber, #165) [Link]

Users and maintainers of those other distros are going to regret being stuck with /lib64 and 32-bit /lib, when the world goes to 64 bits.

Those 64-bit EDA tools will work on Debian, too, because of the /lib64 symbolic link, and the regular /lib will be right for the platform. Although there are some programs that run faster in 32-bit mode, it appears that, on average, untuned programs run 8% faster in 64-bit mode. The only problem will be binary-only 32-bit programs linked to reference /lib, and they will be able to run chrooted, if necessary. On Debian systems that won't be so important.

I am happy to learn that of all the distributions, Debian (and perhaps Gentoo?) made choice that will be recognized as the right one next year.

x86-64 distros needn't cripple themselves to support 32-bit.

Posted Jun 13, 2004 16:21 UTC (Sun) by JoeBuck (subscriber, #2330) [Link]

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.

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 even
more often in theory. Why not solve it the right way?

Either libraries should have the arch as part of the filename, there
should be subdirectories for each arch under library directories, or there
should be a directory for each arch.

So you could have one of these:

a) /lib/libc-N.N.N-arch.so
b) /lib/arch/libc-N.N.N.so
c) /lib-arch/libc-N.N.N.so

This would be nice for changes which didn't involve word-size changes.
Such things could include different calling conventions, new processor
instructions, or even emulated systems (so I could have sparc32 and
sparc64 libraries installed in a sane location). This would be really
nice for CDs which boot on multiple types of systems and for libraries
which are compiled with new instructions. For example, both Pentium II
and i386 libraries could exist on a single image and the dynamic linker
could use the right one automatically.

Is this overdesigned, non-Unix-like, too big of a change, or what? It
just seems like anything short is not addressing the real problem.

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'm
happy with the planned changes.

x86-64 distros need to support 32-bit

Posted Jun 13, 2004 3:24 UTC (Sun) by alexperry (guest, #4291) [Link]

> Unfortunately, the shipping distros for x86-64, from SuSE and Red Hat, are mixed 32/64 bit

Yep, that's why I'm not using them. From the point of view of doing software development for in-house needs, it is a lot more hassle to support a biarch (32/64) environment than a single native architecture ... and I can't justify the additional effort for the projects I'm working on.

> They are shipping now; Debian is chasing.

RH and SuSE paid a lot of money, plus signing NDAs, to get earlier access to the information and thereby get to the marketplace sooner. They benefit from short term market share and revenue from selling their distributions. I wish them good luck (not that they need it).

> Now, perhaps it's possible for Debian to start out as 64-bit only and cleanly add the 32-bit stuff later.

Debian has a pure64 arch (this one), a 32/64 biarch (still experimental) and is planning to develop a multiarch that isn't just limited to 32/64.

> with Debian they won't be able to run any code that is only available as x86 binary code (video codecs, Wine, games, etc).

I don't have any trouble. I use the proprietary 32 bit X server even though my entire desktop and all apps are pure 64 bit. The only game I play, FlightGear, compiles and runs cleanly in 64 bit so I'm happy there 8-). My 32 bit engineering tools seem to be quite happy with a chroot environment.

x86-64 distros need to support 32-bit

Posted Jun 13, 2004 10:51 UTC (Sun) by mjr (subscriber, #6979) [Link]

SuSE and Red Hat are shipping multilib'd distros (supporting both 32-bit and 64-bit binaries). They are shipping now; Debian is chasing. It's not a good idea for the chaser to be clearly inferior, and not supporting 32-bit means that you're inferior.

Correct, to an extent and to some user groups. Some users probably don't care significantly (I know I won't), and anyway, it's better to have single-arch amd64 port than none at all. (Not denying that multiarch support will be a good thing when it gets there in a clean way.)

For many apps, 32-bit code will be faster on the Opteron than 64-bit (32-bit tuned code, that is, not the Debian i386 stuff)

Hmh, not sure what you mean by 32-bit tuned code (perhaps hand-written assembly?) but as 64-bit code on the amd64 can access way more general purpose registers and stuff it's likely to be superior to the 32-bit mode in many applications. (This in contrast to eg. sparc32/64, where sparc32 code is often faster, but where the sparc64 code also doesn't have clear advantages besides the larger address space.)

Now, perhaps it's possible for Debian to start out as 64-bit only and cleanly add the 32-bit stuff later. But until this is corrected, people with an Opteron box who aren't RMS-style purists will want to run SuSE or Fedora

Perhaps they will. At least now they can also make a choice whether to use Debian with the caveats, or one of those other systems. To each his own.

x86-64 distros need to support 32-bit

Posted Jun 13, 2004 12:11 UTC (Sun) by sveinrn (subscriber, #2827) [Link]

>Unfortunately, the shipping distros for x86-64, from SuSE and Red Hat,
are mixed 32/64 bit,

I am using Redhat on my AMD64, and it is possible to install and run
without a single 32-bit package. So I see it as a pure 64-bit version. It
is also possible to install 32-bit versions of some of the libraries to
be able to install and run binary packages or compile applications that
won't compile in a 64-bit environment (like OpenOffice, which is included
as a 32-bit package). And I must admit I have problems understanding why
this should be a bad thing...

x86-64 distros need to support 32-bit

Posted Jun 13, 2004 17:48 UTC (Sun) by viro (subscriber, #7872) [Link]

The _what_, again? Care to apologize? Comparison with RMS is a hell
of a dirty insult and I don't see how TF does using amd64 boxen for
normal work (you know, the boring stuff - development, testing;
nothing exiciting, in a word) earn it. Sheesh...

x86-64 distros need to support 32-bit

Posted Jun 14, 2004 4:05 UTC (Mon) by JoeBuck (subscriber, #2330) [Link]

I have nothing but admiration for RMS, even though I am not the free software purist that he is. To me, comparison to RMS is not an insult. If, like RMS, you don't care to run any code you don't have the source for, it's no problem for you if LSB-compatible binaries don't run on your Debian box; you can port them.

x86-64 distros need to support 32-bit

Posted Jun 13, 2004 18:35 UTC (Sun) by zender (subscriber, #10453) [Link]

I installed SuSE 9.0 on my x86_64 only because debian was not ready.
Although SuSE has bi-arch, it lacks the convenience of debian package
handling and "up to dateness" we expect from Sid. Since I do development,
not business, applications, I'm one of the many who can now move my x86_64
to Debian. I will not miss SuSE at all. This is really good news, congratulations to the x86_64 team for completing the port.

Charlie