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

[Guillaume POIRIER]

Hi,

On 9/20/06, Rich Felker <dalias at aerifal.cx> wrote:
> On Wed, Sep 20, 2006 at 05:35:11PM +0200, Guillaume POIRIER wrote:
> > Hi,
> >
> > On 9/20/06, Rich Felker <dalias at aerifal.cx> 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: 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.

Arg!

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

Guillaume
-- 
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!