Re: mplayer

[Billy Biggs <vektor@dumbterm.net>]

Andrew Suffield (asuffield@debian.org):

> On Tue, Jul 15, 2003 at 11:59:19PM +0100, Andrew Suffield wrote:
> > On Tue, Jul 15, 2003 at 03:13:06PM -0700, Mike Fedyk wrote:
> > > On Tue, Jul 15, 2003 at 12:25:19AM +0200, martin f krafft wrote:
> > > >   Another impediment to binary redistribution were compiletime
> > > >   optimizations for CPU architecture. MPlayer now supports runtime
> > > >   CPU detection (specify the --enable-runtime-cpudetection option
> > > >   when configuring). It is disabled by default because it implies
> > > >   a small speed sacrifice, but it is now possible to create binaries
> > > >   that run on different members of the Intel CPU family.
> > > 
> > > why isn't the part needing the optimizations put into a seperate library,
> > > and let ld choose the correct library based on cpu type?

  At runtime?  How does this work?  I don't understand this suggestion.

> > > That should avoid any speed penalties.
> > 
> > The mplayer developers needed run-time CPU detection to be slower than
> > compile-time, so they implemented it in a broken fashion.
> 
> Oh, that or they're completely inept. I guess I should apply Hanlon's
> razor here. But we're talking ineptitude on the scale you'd expect
> from somebody who just started programming.

  Maybe you'd like to educate us on how to select optimized routines at
runtime without penalties.  I know that in my application I have
gratuitous use of function pointers to deal with this.  What do you
recommend I do to avoid that penalty?

  -Billy