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] '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
