Debian x86_64 port ready
| From: | Chris Cheney <ccheney-AT-cheney.cx> | |
| To: | debian-devel-announce-AT-lists.debian.org | |
| Subject: | Debian AMD64 Port Ready | |
| Date: | Fri, 11 Jun 2004 20:35:55 -0500 | |
| Cc: | 248043-AT-bugs.debian.org |
We are proud to announce the Debian AMD64 port is ready for inclusion in
Sid. The port is currently at 97% compiled with most of the remaining
packages having FTBFS RC bugs filed for unrelated reasons. We have also
finished debian-installer for the AMD64 port and generate daily builds.
All that still remains to be done is for dpkg to include the amd64
patch, for archive space be given to the port, and for an official
buildd to be setup.
Thanks,
Debian AMD64 Port Team
---------------------------------------------
Package Details (counted in source packages):
Known: 7972 ( 8200)
Installed: 7719 [ 97.00%]
Uploading: 14
Building: 0
Needs-build: 0
Dep-Wait: 61
Failed: 11
Broken: 167
Not-For-Us: 228
Popcon stats:
1 i386 : 4183
2 powerpc : 78
3 sparc : 46
4 alpha : 18
5 amd64 : 13
6 hppa : 7
7 arm : 6
7 ia64 : 6
9 mips : 5
10 m68k : 4
11 mipsel : 3
12 hurd-i386 : 2
12 s390 : 2
unknown : 1231
Posted Jun 12, 2004 21:25 UTC (Sat)
by ncm (guest, #165)
[Link] (17 responses)
Does this release use gcc-3.4, or the old 3.3? Is /lib compiled 64 bits, or 32, with a separate /lib64? (This sort of thing would be a lot easier to accommodate if we could expand environment variables in symbolic links.)
Posted Jun 13, 2004 0:23 UTC (Sun)
by alexperry (guest, #4291)
[Link] (15 responses)
gcc --version => gcc (GCC) 3.3.4 (Debian) > Is /lib compiled 64 bits, or 32, with a separate /lib64? Yes, /lib is pure 64 bit; there are no 32 bit libraries in there. http://alioth.debian.org/docman/?group_id=1314
Posted Jun 13, 2004 0:55 UTC (Sun)
by JoeBuck (subscriber, #2330)
[Link] (14 responses)
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).
Posted Jun 13, 2004 1:42 UTC (Sun)
by ncm (guest, #165)
[Link] (7 responses)
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.
Posted Jun 13, 2004 16:21 UTC (Sun)
by JoeBuck (subscriber, #2330)
[Link] (6 responses)
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.
Posted Jun 13, 2004 17:06 UTC (Sun)
by loening (guest, #174)
[Link] (3 responses)
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.
Posted Jun 13, 2004 18:15 UTC (Sun)
by stevenj (guest, #421)
[Link]
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.
Posted Jun 14, 2004 4:01 UTC (Mon)
by JoeBuck (subscriber, #2330)
[Link] (1 responses)
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).
Posted Jun 14, 2004 9:09 UTC (Mon)
by joib (subscriber, #8541)
[Link]
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... ;-)
Posted Jun 14, 2004 2:42 UTC (Mon)
by Ross (guest, #4065)
[Link] (1 responses)
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
Posted Jun 14, 2004 3:48 UTC (Mon)
by Ross (guest, #4065)
[Link]
Posted Jun 13, 2004 3:24 UTC (Sun)
by alexperry (guest, #4291)
[Link]
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.
Posted Jun 13, 2004 10:51 UTC (Sun)
by mjr (guest, #6979)
[Link]
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.) 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.) 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.
Posted Jun 13, 2004 12:11 UTC (Sun)
by sveinrn (guest, #2827)
[Link]
Posted Jun 13, 2004 17:48 UTC (Sun)
by viro (subscriber, #7872)
[Link] (1 responses)
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.
Posted Jun 13, 2004 18:35 UTC (Sun)
by zender (guest, #10453)
[Link]
Charlie
Posted Jun 13, 2004 2:53 UTC (Sun)
by calc (guest, #22286)
[Link]
Posted Jun 13, 2004 7:59 UTC (Sun)
by joib (subscriber, #8541)
[Link]
Is there any chance that this will get included into sarge? Personally, I think that x86-64 is going to be very popular in a couple of years, so having native support for it would be a big plus for many users. Another question, how has the compiler tuning settings been used? As the i386 arch has to support anything from the 386 upwards, debian can't really use any fancy stuff here (although I believe that the minimum supported architecture should be bumped to i486 for many reasons, but that's a different topic). But on the x86-64 there are no such legacy concerns, so nobody is excluded if the binaries are compiled using say SSE2 for fp math, and they can be tuned for the opteron instead of the 386, right? Although 3dnow might be problematic, if Intel won't support it in their version of the x86-64 architecture, but OTOH if MMX/SSE/SSE2 can be used there's not much use for 3dnow.
Posted Jun 13, 2004 16:48 UTC (Sun)
by BrucePerens (guest, #2510)
[Link] (7 responses)
Debian continues to work on bi-arch, but doing it right is harder than making two separate ports. Bruce
Posted Jun 14, 2004 4:09 UTC (Mon)
by JoeBuck (subscriber, #2330)
[Link] (2 responses)
Doing it right will require the various distros to talk to each other and not insist on re-inventing the wheel. Certainly those who say that the SuSE/Red Hat approach has some warts that we might regret later. But I am interested in portable code.
Posted Jun 14, 2004 5:38 UTC (Mon)
by JoeBuck (subscriber, #2330)
[Link]
Certainly those who say that the SuSE/Red Hat approach has some warts that we might regret later have a good point.
Posted Jun 14, 2004 9:26 UTC (Mon)
by joib (subscriber, #8541)
[Link]
I think they made the right choice in focusing on a "pure64" architecture. It's the simplest approach, and if the wheels of bureocracy turn fast enough, they might get included in sarge. Doing a multiarch thing now would certainly have meant they would not have any chance of making it to sarge, and perhaps they would have to redo it later anyway, when the FHS/LSB thing is finished.
Posted Jun 14, 2004 7:58 UTC (Mon)
by tov (guest, #22303)
[Link] (3 responses)
Posted Jun 14, 2004 8:34 UTC (Mon)
by pharm (guest, #22305)
[Link] (2 responses)
That sounds good! Is it possible you could post these commands here for reference, please? Probably something like:
Posted Jun 14, 2004 8:44 UTC (Mon)
by pharm (guest, #22305)
[Link]
Incidentally, this is all described in detail in the Debian sarge installation manual, wherein you can also find other useful tricks like binding a virtual terminal login directly to the chrooted install.
Posted Jun 17, 2004 6:58 UTC (Thu)
by peterhoeg (guest, #4944)
[Link]
apt-get install ia32-libs directly in your pure64 environment and taa daa - 32bit support.
Congratulations to all involved! This is big news.Debian x86_64 port ready
> Does this release use gcc-3.4, or the old 3.3?Debian x86_64 port ready - details
That's basically for compatibility with the mainstream Debian/Sid;
GCC 3.4 is better for AMD64 but the port is trying to stay in step.
/lib64 is a softlink to /lib for compatibility with some apps.
x86-64 distros need to support 32-bit
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.
x86-64 distros needn't cripple themselves to support 32-bit.
x86-64 distros needn't cripple themselves to support 32-bit.
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.x86-64 distros needn't cripple themselves to support 32-bit.
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:
32-bit/64-bit performance comparison
x86-64 distros needn't cripple themselves to support 32-bit.
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.
x86-64 distros needn't cripple themselves to support 32-bit.
There's a problem. It has come up more than one in practice, and evenWhy the band-aid?
more often in theory. Why not solve it the right way?
should be subdirectories for each arch under library directories, or there
should be a directory for each arch.
b) /lib/arch/libc-N.N.N.so
c) /lib-arch/libc-N.N.N.so
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.
just seems like anything short is not addressing the real problem.
I just read the comments about multiarch below. Needless to say I'mUrr.. nevermind
happy with the planned changes.
> Unfortunately, the shipping distros for x86-64, from SuSE and Red Hat, are mixed 32/64 bitx86-64 distros need to support 32-bit
x86-64 distros need to support 32-bit
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)
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
>Unfortunately, the shipping distros for x86-64, from SuSE and Red Hat, x86-64 distros need to support 32-bit
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...
The _what_, again? Care to apologize? Comparison with RMS is a hellx86-64 distros need to support 32-bit
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
I installed SuSE 9.0 on my x86_64 only because debian was not ready.x86-64 distros need to support 32-bit
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.
It uses gcc 3.3.4 as someone already stated. We have considered switching Debian x86_64 port ready
over to gcc 3.4 once it is available in Debian Sid. Currently the
libraries are located in lib with a symlink from lib64 to lib due to the
fact that changing the path would require modifications to all library
packages in Debian, which is not really feasible at the current time.
After the Debian Sarge release there are plans to switch Debian over to
something called multiarch which will involve having library directories
laid out like:
/lib/i486-linux
/lib/x86_64-linux
/usr/include/i486-linux
/usr/include/x86_64-linux
/usr/lib/i486-linux
/usr/lib/x86_64-linux
This is so that multiple archs can be supported generically on all
platforms, such as i386/x86-64, i386/ia64, mips (3 different arch types),
powerpc/powerpc64, sparc/sparc64, etc. However, implementing this will
take a long time since there several thousand library packages in Debian
currently.
Chris Cheney
Congratulations!Debian x86_64 port ready
The kernel provides 32-bit emulation. It is possible, indeed very easy, to install a 32-bit Debian system in a chroot environment. It took me 3 commands. With that, you can run any 32-bit application. It is a bit harder to make them run without chroot, but not very difficult. It only takes a small hack to ld-linux.so to make it load libraries from an alternate location even when they are specified with the /usr/lib/ path.
Runs 32-bit applications too
Runs 32-bit applications too
Whoops, meant to say:
let's try that again:
Skimming the debian-amd64 list gives me the impression that FHS/LSB is working on a standard for multiarch support, apparently it will look something like Chris Cheney described briefly a couple of messages above this.Runs 32-bit applications too
It is possible, indeed very easy, to install a 32-bit Debian system in a chroot environment. It took me 3 commands.Runs 32-bit applications too
That sounds good! Is it possible you could post these commands here for reference, please?
Runs 32-bit applications too
$ mkdir /debian-i386
$ debootstrap --arch=i386 sid /debian-i386
$ chroot /debian-i386
at a guess.
$ apt-get install debootstrap
if you haven't got it installed already.
Runs 32-bit applications too
Alternatively you can use:Runs 32-bit applications too