Re: [linux-audio-dev] Re: high level laaga

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Re: high level laaga
From: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Fri May 11 2001 - 22:22:51 EEST


On Fri, May 11, 2001 at 11:34:32AM -0400, Paul Davis wrote:
> Yes, these are both real issues. However, if and when the
> single-thread model is accepted, they are just part of the unpleasant
> facts of life.

Not that I doubt Pauls experiences of IPC based plugins, but just to find
out what the differences are I tried mocking up a test of single thread
v's ipc plugin processing.

I wrote one process that just executes 8 identical functions N times, in
sequence.

I compared this to one controlling process that launches eight different
proccesing processes, each of which does the same as the funtions in the
single thread. Each procees is woken up with a signal, it does its stuff
and then sends a signal back to the controlling process, which then wakes
the next process in turn until its woken 8*N processes.

The test process looks like:

void proc() {
        int i;
        float filter[FILT_SZ];

        for (i=0; i<FILT_SZ; i++) {
                filter[i] = i*0.754355f;
        }

        for (i=0; i<DATA_SZ; i++) {
                data[i] = data[i] * filter[i % FILT_SZ];
        }
}

The only significant differences are that each seperate process has its
own data[] block, whereas the single thread version shares one between the
8 functions (this favours the single thread version I think). Also, the
signal handler in the processes takes no arguments, whereas the single
thread version takes a pointer to the data to process (which favours the
multi process one slightly).

The result is that the multi process version takes 2.58s to process 10240
256 byte chunks and the single threaded one takes 3.64s!
(this is on a lightly loaded dual PIII 866/133 512meg CL2 machine) not
ideal test conditions, but I figured it didn't really matter.

I was expecting the multi process one to be a bit slower, so that came as
quite a supprise. I suppose the extra speed might be due to utilisation of
the caches of both processors, also there might be a bug, but the code
gets executed the right number of times, and the single threaded code is very
simple. I tried knobling the multi process code, by wrapping the signal
handler, but it made next to no difference.

I'l try it on my single processor machine at home and see what difference
that makes.

If anyone wants to try the code its at
http://plugin.org.uk/ipc-vs-sp.tar.gz

run ./sp for the single thread and ./mp, then run the trigger command it
sends to stdout to test the multi process one.

Interesting. Or maybe I've just forgoten how to write code ;)

- Steve


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri May 11 2001 - 21:39:24 EEST