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

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

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.


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

Dropping frames ;)

> 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


				Attila Kinali

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