Re: to be effcient or not to be efficient

* Steve Lhomme <[email protected]> [2004-01-14 09:41:50 +0100]:

<snip>
> 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)
ACK.
We perhaps should provide some additional information for aiding MT
and some codecs and filters of course _MAY_ use MT, but it should not 
be in scope of this API. But if we use a machine readable description
for modules (as I stated in my draft for the module/lib handling),
it should contain a flag which tells us if some module uses MT, just
in case we need to know it.

<snip>
> 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 
Well, there are realtime OSes (or extensions) which make scheduling 
predictable. But MT/MP tends to add context switching overhead and some
other difficulties (i.e passing data safely from one thread to another)

<snip>
> >>>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...
They're using completely different platforms there. For example QNX
is a realtime kernel, which allows quite exact task scheduling. RTlinux
also provides such features. But you cannot expect most platforms to
be able to work efficiently w/ MT for realtime applications.

<snip>
> >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.
No, its not a question of the kernel - it depends on the underlying hardware.
All multitasking CPUs I've ever seen are working this way - except 
multiprocessor-machines, which have _real_ multitasking, but on those 
machines still processes and threads are just two kind of tasks.

<snip>
> >>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.
Okay. Especially for seeking etc it could be very useful.
So we perhaps should add an interface for configuring caches/buffers
and similar stuff. (perhaps sth like a generic sysctl interface, which
allows us to read and write named variables?)

> >BTW: how can get best benefit from mmap() in the storage or demux ?
> 
> I don't know what mmap() is.

well, mmap() maps a file into memory space. You just tell the kernel
"put the given area in the given file into memory". Depending on the
given flags you can consider the returned memory range identical to
the given range in the file. It is a little bit like virtual memory
in a swapfile (well, technically its almost the same). 

the userland application can then access simply a memory range. the 
interaction w/ the underlying filesystem is the job of the kernel, 
which should know best how memory should be handled. userland code
has no longer to do w/ buffers etc ...

I dont know whether win32 supports such a fundamental thing ...

cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     [email protected]
  cellphone: +49 174 7066481
---------------------------------------------------------------------
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/