to be effcient or not to be efficient

Hey there,

I'm now following this discussions here for a few days and i'm
surprised how less knowledge there is about how modern computers 
work and what the bottle necks of video processing applications are.
I like to advice everyone to read the code and documents describing
the internals of MPlayer, Xine and VLC. Those 3 are the most used
because they are not slow as hell like most other video projects.
You should especialy read the MPlayer G2 video pipeline API draft
from Rich (http://brightrain.aerifal.cx/~dalias/vp-in-progress/),
it adresses most problems which MPlayer G1 (the current implementation)
had in the past implementing and optimizing filters and data transfere.

Now to the arguments mentioned here:

Message passing:
You have to be very carefull to make message passing efficient.
It can be nearly as fast as procedure/function calls, but the
message composition and decomposition takes time and this
is a something that will be done a few 1000 times per second.
And even if it uses just 1us (around 1000 Cycles on a 1GHz cpu
which are about 300-500 asm instructions on x86)
it'll be over 1ms cummulative time per second, not taking into
account the time to load this code into the L1 cache.

EBML:
I'm strongly against this idea. EBML is for structured
data. Where do you see structures in pictures ?
You have the picture itself plus some attributes (FOURCC,
resolution, pts,...). No structure at all. If you even
think to package the picture itself in ebml you can forget
to run this API on anything below a 20GHz cpu.

framedrop:
Framedrop has to be done as early as possible, which 
means it has to be done in the codec. Anything else is
a waste of cpu cycles and you'll even have to drop more.

seeking:
Seeking is not so simple as it looks, the codec and
all filters have to know that a seek occured.

endianes problems:
In an API there wont be any endianes problems at all.
You run the library and the program on the same machine.
There is no interface between different architectures
that need to handle endianess. The only parts that
have to take care about this are the demuxers and
codecs but those are outside the scope of an API.
So, no need to add more abstractions for this case.

memcpy:
Something not mentioned here at all. memcpy is the thing that uses 
the most time in video apps. Why ? Because todays PCs are optimized 
for number crunching not for transfering data. Thus the cpu waits 
most of the time for data comming from RAM, going to the graphics 
card or some other IO (IDE access block the whole mainboard, eg). 
Any cache doesnt help here at all because the caches have still the 
same size as they did 5 years ago and this is easily flooded by the 
video data thus every memory access becomes a cache miss.
A good API has to avoid a memcpy when ever possible.


I can fortell you that if you dont think about efficiency and
only try to implement a nice structered interface that would
please every CS professor, noone will ever use this API.
So get back on the ground and start engineering an API
that is worth using and does not do a lot of unecessary things
just because it has to be extendable and someone might want
to use this or that feature in an unknown future.


			Attila Kinali

-- 
egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger
			-- reeler in +kaosu