Re: to be effcient or not to be efficient

* Steve Lhomme <[email protected]> [2004-01-06 23:00:18 +0100]:

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

Why limited ?

Once we have an API interface, it will be never changed. Of course you
may extend it and create a new derived one, but old stuff may never be
changed. If we want to have a good library which should be used by all
projects interested in such things, so consitency is very very important.

For example we could have a simple frame based video filter, it can 
work with a API which does not much more than throwing frames in and
getting filtered frames out. Lets call this Interface FILTER-1.

struct API_FILTER_1
{
    char api_name[8] = 'FILTER\0';
    char api_version = 1;
    void* privdata;

    int         (*throw_frame)(struct API_FILTER_1* filter, VIDEO_FRAME* frame);
    VIDEO_FRAME (*fetch_frame)(struct API_FILTER_1* filter)
};
    
Perhaps someday we want to have a method for finding out the latency
(i.o.w. how many frames must be fed in before a frame comes out),
we could extend this interface to have some new features:

struct API_FILTER_2
{
    char api_name[8] = 'FILTER\0',
    char api_version = 2;
    void* privdata;

    int         (*throw_frame)(struct API_FILTER_2* filter, VIDEO_FRAME* frame);
    VIDEO_FRAME (*fetch_frame)(struct API_FILTER_2* filter)
    get_latency (struct API_FILTER_2* filter);
};


If we someday want to do something completely new, we can invent a completely 
new interface and just adapt it for compatibility (i.e. w/ some macros).

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

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

<snip>
> 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.
The MT variant also requires such mechanisms. You cant simply write 
anything into thread-shared memory - you also need locking and integrity
assurements. All in one it will eat up much time than select()-loops.

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

If you mean a file cache, well thats a job for the storage/demux.

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

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/