Re: [Ffmpeg-devel] [RFC] use optimized routines "à la" SMP-alternatives

Guillaume POIRIER poirierg
Fri Sep 22 09:44:31 CEST 2006


On 9/20/06, Rich Felker <dalias at> wrote:
> On Wed, Sep 20, 2006 at 05:35:11PM +0200, Guillaume POIRIER wrote:
> > Hi,
> >
> > On 9/20/06, Rich Felker <dalias at> wrote:
> > >On Wed, Sep 20, 2006 at 10:37:10AM +0200, Guillaume POIRIER wrote:

> 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
> features.

Yeah, I share your point of view, though I do run a 2.6.x kernel
(ubuntu's 2.6.15) just because I wouldn't have the proper hw driver
support if I weren't using a recent kernel.

> > 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
> decoder instances.

Ah! This is the thing I failed to consider while looking at this
solution. Thanks for highlighting this to me.

> 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
> applications.

Isn't the "funny code" supposed to be somewhat self-modifying code?
I don't know, it's just that I vaguely remember it was an issue when
we added support for non-executable stack...

> > 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! :)

Yeah, sure, but I'm fireproof.

> > 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:
> > (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.


GNU is indeed somewhat following the footsteps of Microsoft on the
"embrace and extend" strategy (c.f. the discussion on the "visibility"
patch). Bummer!

With DADVSI (, France finally has
a lead on USA on selling out individuals right to corporations!
Vive la France!

More information about the ffmpeg-devel mailing list