Dear Yumsters (mostly Seth), Opterons have been kicked around some on the beowulf list since the list came back up yesterday and today. I was pointing out that I don't really know how fast they run i386 code because our Opterons were missing the i386 compatibility libraries, primarily glibc but possibly others. It is reported by a lot of people that Opterons actually are the fastest way possible to run >>i386<< code these days, even without a recompile and I'm interested in testing this if/when it works out. Other than this, this isn't a major problem for me personally; our Opterons are all relatively thin compute nodes and it takes a second to recompile an x86_64 version of the program I'm working on. It may become more of a general issue as they start appearing on desktops. In any event, I write because somebody on the beowulf list asked how one would kickstart-install and yum-update the compatibility libraries. This is actually tough to answer, as a bit of the exchange below indicates. The libraries (unfortunately) have the same name as their x86_64 counterparts, so working by package name per se, e.g. yum install glibc won't work (glibc is already installed, x86_64 version). I imagine that I could download the rpm's (for compatibility libraries) to the machines and use rpm to install them by full name, if they are built to be installable at the same time as the x86_64 libraries the way Don describes below -- libraries only, no configuration or documentation, non-conflicting names and paths but that is a bit of a pain. If the existing i686 glibc in the x86_64 repository is indeed built so it can run at the same time as glibc x86_64, it might be worthwhile to rename the rpm something like glibc_compat32 or glibc_i686 so it (and others built for the same purpose) could be kickstart installed and yum updated, unless there is a better solution. I'm posting the question here because it seems at least partly a yum issue -- yum can find both glibc's: [root@s02 rgb]# yum list glibc Gathering header information file(s) from server(s) Server: Fedora Core 1 - x86_64 - base Server: Physics RHL Server: Fedora Core 1 - x86_64 - updates Finding updated packages Downloading needed headers Looking in Available Packages: Name Arch Version Repo -------------------------------------------------------------------------------- glibc i686 2.3.2-101.4 base Looking in Installed Packages: Name Arch Version Repo -------------------------------------------------------------------------------- glibc x86_64 2.3.2-101.4 db but install/update only refers to the x86_64 version. rgb -- Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@xxxxxxxxxxxx ---------- Forwarded message ---------- Date: Fri, 14 May 2004 19:33:32 -0400 (EDT) From: Donald Becker <becker@xxxxxxxxx> To: Greg Lindahl <lindahl@xxxxxxxxxxxxx> Cc: beowulf@xxxxxxxxxxx Subject: Re: [Beowulf] Athlon64 / Opteron test [[ The mailing list should now be back up and running for all subscribers. I'll write up the long story of the Beowulf Mailing List problems over the weekend, assuming that everything continues running. - DJB]] On Fri, 14 May 2004, Greg Lindahl wrote: > On Fri, May 14, 2004 at 11:49:34AM -0400, Robert G. Brown wrote: > > > rgb@s02|B:1003>./Ospin > > -bash: ./Ospin: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory > > rgb@s02|B:1004> > > Pilot error. You have to install a couple of additional rpms to run > 32-bit stuff on an Opteron. The annoying thing about it is that they > have the same names as x86_64 packages, grrrr. In this case you need > glibc-*.i686.rpm. That makes it sound easier than it really is... We distribute 32 bit library RPMs with the Scyld Beowulf for AMD64 distribution. But those libraries are not just a simple duplication of the x86 32 bit RPMs. The 32 bit library RPMs must contain only the libraries, not other configuration and documentation files. The libraries must placed in the proper directories or otherwise made to have non-conflicting names. Some libraries that exist only as 32 bit versions must be placed in the LSB-standard location. And all of this get extra complicated with 3rd party compilers. We started out with an ad hoc approach, using the 32 bit RPMs, but quickly decided that it had too many exceptions to support for end users. > > ...it also refers to anecdotal accounts that numerical performance > > significantly degrades if one runs i386 code compared to recompiled > > x86_64 code. > ...I don't think that you'd come to that conclusion. It is an apples to > oranges comparison There were list postings in March that pointed to cases where the 64 bit instruction set was more compact and efficient than x86 32 bit native mode, thanks largely to more general purpose registers. The only part that was surprising was the "more compact" part. -- Donald Becker becker@xxxxxxxxx Scyld Software Scyld Beowulf cluster systems 914 Bay Ridge Road, Suite 220 www.scyld.com Annapolis MD 21403 410-990-9993 _______________________________________________ Beowulf mailing list, Beowulf@xxxxxxxxxxx To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
