On Mon, Nov 27, 2000 at 09:32:46PM -0800, Michel LESPINASSE wrote: > On Tue, Nov 28, 2000 at 06:11:47AM +0100, Samuel Hocevar wrote: > > On Mon, Nov 27, 2000, Ben Collins wrote: > > > 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: > > > This looks very elegant, but I'm afraid that the performance gain > > brougth by the 686 compilation might get countered by the lost register > > caused by -fPIC. > > Two things : > > * shared objects do not actually have to be built with -fPIC. They > work fine without it (on x86 at least). libtool can be a pain if you > try to use it, but thats all. > > * for some programs at least, -mcpu=pentiumpro is faster than > -march=pentiumpro. It works on all x86 systems too. For the mmx/sse > stuff, I'm a big partisan of compiling both and using the right one at > run time (using function pointers initialized when you detect the > cpu). This is what mpeg2dec does too.
For mmx, glibc supports things aswell, like: /lib/mmx/ /lib/i586/ /lib/i586/mmx/ ld-linux.so.2 and ldconfig (in glibc 2.2 atleast) can detect these things and choose the appropriate subdirectory. I suggest using glibc's built-in mechanism. -- -----------=======-=-======-=========-----------=====------------=-=------ / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=========------=======-------------=-=-----=-===-======-------=--=---'
