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

Re: mplayer

Andrew Suffield (asuffield@debian.org):

> > 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?
> Same thing you do with every similar performance issue. Push it
> outwards from the inner loop until it's no longer a problem.
> This is really basic stuff...
> Throw me some simple code and I'll demonstrate the transformation, but
> when it comes to something like mplayer, I just don't care enough to
> fix their braindamage. It's easier to use xine, which is faster anyway
> on an SMP box (and some modern non-SMP boxes).

  In my application, I have function pointers like this:

  extern void (*interpolate_packed422_scanline)( uint8_t *output,

  I then have multiple implementations (interpolate_blah_[c,mmx,
mmxext,sse2]) and I set the function pointer at program startup to point
at the best available one.  When I'm doing a complicated filter or
something, I can call through the function pointers to the appropriate

    /* Interpolate scanline. */
    if( bottom_field ) {
        quarter_blit_vertical_packed422_scanline( output, curframe - (instride*2), curframe, width );
    } else {
        if( i > 1 ) {
            quarter_blit_vertical_packed422_scanline( output, curframe + (instride*2), curframe, width );
        } else {
            blit_packed422_scanline( output, curframe, width );

  I don't want to have multiple implementations of this high level code,
but I also don't like having to go through a function pointer for every
scanline function.  I don't know how significant the penalty is, so
maybe it isn't worth bothering, but there is some cost here and I'd like
to know what these obvious and penaltyless methods are that you guys are
mocking the mplayer developers over.

  It's just like the PIC problem.  Libraries that aren't PIC suck, but
libraries that are PIC are slow.


Reply to: