[Yum] Re: [Beowulf] Athlon64 / Opteron test (fwd)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux