Re: to be effcient or not to be efficient

----- Original Message -----
From: Attila Kinali <[email protected]>
Date: Wed, 7 Jan 2004 18:22:32 +0100
To: "The attempt to create a new,  open standard codec API" <[email protected]>
Subject: Re: [Media-api] to be effcient or not to be efficient

> On Wed, 07 Jan 2004 11:16:54 -0500
> "Toby Hudon" <[email protected]> wrote:
> 
> Could you please fix your mail client to break lines
> at 65-75 characters ? Thanks.
> 
> 
> > > 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.
> 
> Who ever does a switch over a few hundred cases in a time
> critical application shuld be shot anyways. There are
> ways to handle this effciently.
> 

Then I'd like to hear it, because my last CS professor's idea of "efficient" switch handling was replacing a 22 case switch with a system where you have a class with a pure virtual function and then inherit from it for 22 subclasses, then in each subclass implement the virtual function which the orignial function call calls in place of the switch, so that your code is dependant on which subclass is being passed to the calling function. Oh and do this kinda thing for every possible function like execute, print, etc. Because as we know a 22 entry switch statement would be bad and cause bugs. Much more so than several hundred lines of code in 30 seperate files.

BTW I dropped out last year after his class was impossible to pass without cheating. Sorry I can't rewrite an entire compiler in a language I've never used before to support new features for a language I've never heard of before in 3 weeks and then follow up with a full virtual machine and debugger in 2 more without having more than just myself to do this in the middle of all my other classes.

> As i already wrote, there are no endianess problems, 
> byte allignment and padding isnt a prob as all languages
> i know which can handle c libraries handle them exactly
> the same way or have some switches to change it.
> 

Ok, sounds good to me then. I'd prefer the structs even if we have to generate new version/depreciated structs instead of just modifying the EBML things. It's one complexity trade for another and EBML has the bigger cpu hit.

> Dropping frames ;)
> 

Ah, hadn't thought about that much till now. Did you read my section on latency reporting?

> > 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.
> 
> That's right, it should not have more than a few entry points,
> but also not more than a few message types. 
>
> I think there should be first some use cases written down as
> there are only some vague ideas what can be done with such an API
>

Ok, let's consider doing that then. Let's see, just off the top of my head:

get data, in sequence (playback)
get data, random access (seek)

write data, in sequence
not sure if we'd ever have a non-sequential write (encode)

capabilities reporting messages? Or do we just use try and if fail try something else? Note you could just set an internal flag on the first success to remember what to do on every subsequent call for the remainder of the video so you only have the mutliple call overhead once.

variants on these for the various data types (frames, subtitles, audio)

We probably want init as a seperate API function, not a message.

That's basicly all VFW has for codecs, it's got like 4 functions to just get the info about what's coming, find out if it can compress, and setup the codec. Then 99.99% of the calls go to the main compress or decompress function.
 
I'm probably forgetting some other important things but please help me out on it.
-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm