Re: to be effcient or not to be efficient

On Tue, 06 Jan 2004 23:00:18 +0100
Steve Lhomme <[email protected]> wrote:

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

I dont know DShow at all, i know only MPlayers and parts of VLCs
code. My conclusions here a based on this and on the knowledge about
how modern computer work and where their performance limits are.
 
> 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).

All functions beside init and uninit are speed sensitive as they
might be called in every filter a few times for every frame.
 
> 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.

There is a limited amount of information anyways, so you can add
99% of it into the struct right now. If there will be any new
kind of information that could be added we can talk about a new
version of the api. And as it's really unlikely that elements
are removed you can even keep the structs compatible by adding
the new elements at the end.
 
> > 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 ?

Have a look at MPlayer G2s vp API (you have read my last mail, did you ?)
 
>  > Multithreading:
>  > Multithreading is nice for Java, which is slow anyways.
> 
> That's why Apache moved from process to threads...

Yes, and Apache is a video aplication and we can use it as
an example.

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

LOL, you should go over your books again. I'm not mixing anything.
You have context switches on both tasks and threads. The only
difference is that you can share the page table between the
different threads thus saving a TLB flush if you switch between
threads of the same task (but not all threading implementations do this).
Be also aware that most threading implementations map threads onto
tasks.

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

heh... The efficiency comes from this pushing and pulling.
If you manage the buffers the right way you can pass the data
right away trough filters that do not touch that part of the image
at all. Beside, a filter that takes a lot of time to do its work
will have an impact anyways as it will delay the picture.
Forget the idea that you can have 2 tasks working on different
frames, it will not gain you anything as the cpu is already
working at its limit but you'll have 2 threads poisening
each others cache.


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

Caching of what? Caching of pictures ? No need to do so.
Using the L2 cache efficently ? Forget that, the amount
of data that is handled is way bigger than the current L2
caches of current desktops (unless you have a Blade 2000).
The only place where you can optimize for caches is in 
the filters themself by intelligently accessing the data
and keeping the code small.

				Attila Kinali

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