[MPlayer-dev-eng] MplayerXP vs Mplayer. Hall of truth.

[Gábor Lénárt]

On Sun, Mar 17, 2002 at 05:22:35PM +0100, Arpi wrote:
> > I've speedup it on 200-300%! Why don't want such solid speedup and still int
> > erested
> > in invisible performance grow?
> 
> it's not more than your dreams or false suspects...
> 
> avg benchmark won't change, so it won't be faster a single bit!
> it will be smoother on systems fast enough for avg decoding but not fast
> enough for decoding very complex frames in time.


BTW, I don't understand why threading makes things faster (of course on
single CPU system, on SMP it's true of course). Maintaining multiple contexts
by scheduler makes a bit SLOWER not faster. The fastest possible way to
implement an algorithm on UP systems is using only ONE thread (of course
it can be true that it makes it smoother a bit but also it will be slower).
I'm not against threading (I likes them unlike Arpi ;-) but for tasks where
it's simplier to implement something with threads and it's not so performance
bottleneck like when I would have liked to implement GUI as a thread.

Just inmagine: an algorithm (whatever complex) is faster to run it in once
not dividing into several concurent pieces of control flow (threads now),
since the performance of an UP system will NOT be greater if you run
several processes at once instead of one, of course. For losing speed you
must also keep track some sync code between threads, also kernel should
keep track more contextes (threads). So it's pointless.

> the only thing which can realize 200-300% speedup is method-2 direct

method-2? What is it?

> rendering using single buffer in video ram, so for example divxvfw+dga.
> Acki (vo_dga author) could play middle size divx on p1 200 mmx + dga with
> no framedrops. Also windows media player can, using the same trick.
> 
> > I planed to use libvo and libao as static libraries ;)
> hehe

- Gábor