[MPlayer-dev-eng] [PATCH] Dynamic list of EOSD sources
Reimar Döffinger
Reimar.Doeffinger at gmx.de
Tue Sep 14 20:57:46 CEST 2010
On Tue, Sep 14, 2010 at 02:58:23PM +0200, Nicolas George wrote:
> L'octidi 28 fructidor, an CCXVIII, Reimar Döffinger a écrit :
> > > For vf_ass, on the other hand, I see a significant loss of speed. If I turn
> > > eosd_image_{first,next} (the list-walking functions) into static inline in
> > > the header, the performances are once again indiscernible from the original.
> > I don't this makes sense. Can you give use numbers and try to figure out what
> > exactly is going on?
>
> I did some further tests. First of all, I can no longer reproduce the fact
> that inlining the list functions gives the original performance back; I may
> have made a stupid mistake there.
>
> It looks like a problem of cache heat:
>
> - The extra time is spent in my_draw_bitmap, which has not changed at all
> (exactly same machine code if I disable inlining).
Looking at the code without inlining doesn't give you any useful information
at all.
The function call might e.g. cause issues with instruction scheduling or
register reloads which you won't see with inlining disabled.
> - The difference completely disappear on another machine (Thurion 64 instead
> of Core 2 Duo).
Turion is the cheap model, I can't imagine it has more cache.
You could try to __attribute__((always_inline)) the next function
just to see the difference.
I'd also suggest to try marking the while loop that looks for the next source
as unlikely (using __builtin_expect).
But I think the performance degradation is acceptable if necessary, it should be easy enough
to optimize this if necessary/wanted.
More information about the MPlayer-dev-eng
mailing list