Re: [Ffmpeg-devel] [RFC] use optimized routines "à la" SMP-alternatives
Wed Sep 20 17:35:11 CEST 2006
On 9/20/06, Rich Felker <dalias at aerifal.cx> wrote:
> On Wed, Sep 20, 2006 at 10:37:10AM +0200, Guillaume POIRIER wrote:
> > Hi there,
> > While I was reading this article: http://lwn.net/Articles/164121/ a
> > crazy idea came to my mind:
> This is Linux stupidity at its finest.
\o/ Wee! I should have bet one million euros that you would have
jumped on the thread to flame the idea.
Too bad here in France, we can't make bets on lots of random things,
(such as what they do in the UK).
> > Would it be possible to get libavcodec self-optimize itself at runtime
> > by using the tricks described in this article?
> No. Well possible but not without evil evil hacks that are outside the
> scope of what lavc should be doing, not to mention making code pages
> writable and overwriting them.. Why anyone would want to add such
> blatently UGLY hacks is beyond me. If you want speed, compile for the
> proper hardware profile! Don't try to hack every single program to
> runtime-optimize itself!! This is nothing but pure bloat.
Yummy, some more flames!
Ok, here's the idea:
We already have the runtime CPU detection, and the step that chooses
the right optimized routines depending on it, though function
The problem is that I was thinking about is that each time you execute
such routine, you pay the price of an indirect branch, which can be
expensive on some processors (I think PPC970, PM, and maybe K8 are
able to track these in they branch predictor though).
So... if the binary was able to re-organize itself to replace the
indirect calls by direct calls, it may be possible to boost
performance on slow machines.... such as your magnificent K6III.
Whether or not it's a good idea at all is surely debatable, but I
preferred to ask and get you guys feedback instead of not knowing what
to think about this technique.
> > Note that I imagine it won't work any other platforms than the ones
> > that support ELF.
> It's possible to do the same thing without using ELF at all. Kernel
> lusers just think the whole world is a GNU (which somewhat makes sense
> because their build process already depends so heavily on GNU
> toolchain hacks, but that's stupid to begin with..) and therefore use
> the GNU/ELF specific way to do these things rather than simple
> "portable" alternatives.
I honestly don't know if what is described in the article is specific
to Linux or not, however, I'd like to point out that ELF isn't a GNU
(but I imagine you already know that).
Now if GNU managed to fork ELF, that's another story...
With DADVSI (http://en.wikipedia.org/wiki/DADVSI), France finally has
a lead on USA on selling out individuals right to corporations!
Vive la France!
More information about the ffmpeg-devel