Re: to be effcient or not to be efficient

Attila Kinali wrote:

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

Sorry but I've only messed a bit with DirectShow and didn't like it at 
all. But still it does a lot good things. Do you consider it as 
inefficient ?

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

So for some speed sensitive calls, we could request the API for a 
callback and then call that callback instead.
Or use another message "root" for speed sensitive calls (with a smaller 
switch).

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

Each message (or most of it) will have some attached parameters. And 
these parameters will mostly be structures (a list of data). But to make 
the evolution of these structures backward/forward compatible the old C 
way is a bit limited. As if you add/remove something you can hardly know 
where is what.

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

That's also what I had in mind.

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

As already mentioned some of us would like this API to be higly 
efficient for real-time processing (my DJing software but also some 
other video apps). Does any of the API you mentioned support that ? Or 
do they have points that, mixed together, could allow this ?

 > Multithreading:
 > Multithreading is nice for Java, which is slow anyways.

That's why Apache moved from process to threads...

 > But on in a time critical application it should not be used
 > as context switches are very expensive.

You're mixing threads and process. Threads have some advantages of 
processes but are much faster. But still I don't understand how you can 
have something efficient without them. Otherwise you have a very 
monolithic system that only pushes or pulls data and a stage that needs 
more processing once will impact a lot on the other stages.

Also you didn't mention caching. What do you think is a good caching 
policy ?