Re: What to do with optimization flags ?
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
/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=i86 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 \
` firstname.lastname@example.org -- email@example.com -- firstname.lastname@example.org '