Re: to be effcient or not to be efficient

Enrico Weigelt wrote:

>>>Multithreading:
>>>Multithreading is nice for Java, which is slow anyways.
>>
>>That's why Apache moved from process to threads...
> 
> 
> Bad example. Apache is a webserver - not a realtime video application.
> BTW: apache requires multiprocessing for complex modules (CGI, modPHP, ...)
> which cannot be implemented in select() loops. (well, squid heavily uses them)
> so it requires multitasking. multiprocessing has some disatvantages over
> multithreading, because we have separate memory spaces. apache's MT could 
> also be replaced by multiprocessing w/ good shmem handling (we're working 
> on such things in the multiplexer mpm project).
> 
> The the question here is not MT vs. MP, but multitasking vs. singletasking. 
> Task switches always require a lot of time and hard to control in realtime
> fashion. As long as we do not really _need_ it, we should not think about it.

OK OK. I agreed already that threads should not be mandatory for filters 
but a possible "opt-in" option. (for example an audio mixer with 
multiple input)

Now all real-time (where time is critical) systems I know of have tasks 
or (in a lesser extent) threads. The contest switching is known and 
predictable in such systems. Which doesn't mean tasks and threads don't 
help to make the program more reliable and still very efficient... Now 
maybe you think modern OSes don't achieve such requirements. But the way 
they all worked on the Apache benchmark for the past 2 or 3 years shows 
that they tried to compete in that area too (see number of requested 
served by second).

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

Even in military planes they use tasks with time-critical operations 
(where the time to react to anything is vital). Now you have to program 
in a clean way to use them efficiently...

>>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.
> 
> Not really. Threads are the same as processes (at least on linux). The 
> only difference is that you share pagetables. But those stuff should 
> be catched almost automatically by CPUs ...

Please don't consider Linux as the best OS ever done or the root of 
everything. If threads are inefficient there it doesn't mean threads 
just suck.

>>Also you didn't mention caching. What do you think is a good caching 
>>policy ?
> 
> Yeah, caching is always a good idea.
> But what do you really want to cache ?

Future frames (in the case of B frames decoding) ? For example...
Audio not in sync (yet) with the video ? Which can happen at any stage 
of the audio processing.

> BTW: how can get best benefit from mmap() in the storage or demux ?

I don't know what mmap() is.