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

subarchitectures (was Re: What to do with optimization flags ? )

Greetings!  I'm having similar issues with the latest atlas.  Where
can I find out a list of the allowed subdirectories under /usr/lib,
and what cpu's those directories cover?  Specifically, is the Athlon a
686? Is a PII a 686?  I assume a PIII is a 686.  All three of these
would have separate atlas libs, as would the K6, whicn I'm guessing
counts as a 586, but is different atlas-wise from a pentium.

Any suggestions appreciated!

Take care,

On Tue, Nov 28, 2000 at 05:21:14AM +0100, Samuel Hocevar wrote:
>    In the case of CPU-hungry applications such as a movie player,
> MMX and PentiumPro optimizations can sometimes double the app's
> performances. The drawback is that a ppro+mmx binary will only work on a
> ppro+mmx CPU.
>    What can be done about that ? Doing separate packages doesn't look
> very good to me. Doing only optimized binaries isn't acceptable since
> they won't run on most boxes, and doing only non-optimized binaries
> makes the package pretty useless since most users will rebuild it.
>    I thought of doing a package with several versions of the binary,
> with a shell wrapper testing /proc/cpuinfo or whatever, and launching
> the right binary. But this probably means twice to four times the build
> time. Is this acceptable ?

IMO, the better way would be if the CPU intensive portions were in a
shared library (even if the library is only used for this application).
Then you could have one binary program, and do what libc6 does for
optimized libs:

/usr/lib/libfoo.so.1 (normal i386 lib)
/usr/lib/i586/libfoo.so.1 (pentium optimized lib)
/usr/lib/i686/libfoo.so.1 (pentiumpro optimized lib)

(note that gcc sees i586==pentium and i686==pentiumpro, so you can use
-mcpu=i[56]86 for compilation).

After that you do nothing further, and glibc itself will takeover all the
checking to see which optimized library is best.

You can probably talk to upstream about getting the CPU intensive parts in
a lib, and then setup your debian/rules to do the multi builds. Note that
it is very important that you recognize other archs in your build (IOW,
only do this on i386, and not powerpc). However, sparc does support a
/usr/lib/v9/, if you are interested.


/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '

Reply to: