Re: to be effcient or not to be efficient

----- Original Message -----
From: Attila Kinali <[email protected]>
Date: Tue, 6 Jan 2004 22:21:19 +0100
To: [email protected]
Subject: [Media-api] 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.
> 

Yes I'm sure switch(msg) takes a huge amount of time where msg = int32 and all the data associated with it is passed by reference.

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

Fine, I'd prefer to just use regular structs anyway. But when I first mentioned this a few months ago I believe someone started complaining to me about endian, byte alignment, language padding etc. I don't really know much about all that stuff but from what I got the issue was that different languages won't come up with the same structs so you can't just pass them to binaries without knowing what they were compiled under. If this isn't than issue then I'd definately just prefer simple structs.

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

Framedrop?

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

Yes, I know my codec needs to do alot of work on seeks because it has to check frame group boundaries and rebuffer.

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

Fine, let's use structs then if there's really no issues. Are there really no issues? I honestly do not know.

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

That's why I was planning to pass the data by reference.

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

I can fortell that if a codec developer has to worry about 400 mandatory to implement functions each with a different parameter list and documentation as clear as mud like the current APIs, nobody will want to use it either. I was trying to get around the issue of every component needing to respond to every API call.


-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm