[Ffmpeg-devel] [RFC] use optimized routines "à la" SMP-alternatives
Wed Sep 20 20:47:02 CEST 2006
On Wed, Sep 20, 2006 at 05:35:11PM +0200, Guillaume POIRIER wrote:
> 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).
To elaborate on why I said that... Linux is full of bugs,
vulnerabilities, and excessive complexity. And instead of fixing these
fundamental problems that are VERY SERIOUS, the stupid kernel kids are
piling on new hacks.
Piling on new hacks might be acceptable for toys like MPlayer, but
Linux is a kernel, not a toy. These kids need to grow up and focus on
what's important, and that's robustness and security, not gimmicky
> 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.
It's already possible if you just hard-code the optimizations at
compiletime. However, lavc is _already_ using indirect calls for
another reason, reusing the same code between codecs. For example
different IDCT, MC, etc. functions need to be called depending on the
codec and the particular file being decoder. Modifying the code
segment at runtime based on the format being decoded is absolutely out
of the question because it makes it impossible to have multiple
Self-modifying code (and this hack is blatent, shameless smc!!) is and
always has been evil for these exact same reasons. At the kernel level
it may be acceptable, but it's certainly not acceptable for user
> 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.
And you got flames! :)
> 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
> creation: http://en.wikipedia.org/wiki/Executable_and_Linkable_Format
> (but I imagine you already know that).
> Now if GNU managed to fork ELF, that's another story...
They essentually did. The "ELF" format that GNU tools use is full of
GNU extensions. Just look for all the gnu.* crap when you run objdump,
etc. on a GNU-produced "ELF" file.
More information about the ffmpeg-devel