Re: mplayer

[Billy Biggs <vektor@dumbterm.net>]

Andrew Suffield (asuffield@debian.org):

> Here's the problem. You don't want to have multiple implementations at
> this level - but you _do_ want the generated code to be different at
> this level. And you need to bridge this gap.
> 
> Like most problems with programming, it can be solved by introducing
> another layer of abstraction. The preprocessor is a good one.
>
> [...]
> 
> And you're done. Run-time CPU detection with no significant cost.

  Sure, but there is still a cost.  You're just advocating pushing it
higher if performance is an issue (and that's fine, and thanks for the
detailed example with some nifty design ideas).

  FWIW, mplayer's runtime detection compiles different versions of their
post processing code and sets a function pointer at runtime, basically
exactly as I did and as you described.  It's a tradeoff of programming
complexity and how high up to branch to the different optimized
function.  I think my penalty is worse since I have scanline functions
while mplayer's code is per-frame functions, but it does make my high
level frame algorithms look cleaner.

  Until I do detailed timings, I don't see any reason to go further than
my scanline method, and I think mplayer's warning message (while
frightening) is merely a warning about how much work has been put into
their run-time method over simply using the preprocessor and compiling
completely different binaries.  I don't think it was worth the flamage.

  Thanks for the discussion.
  -Billy