Subject: Re: [linux-audio-dev] Article about multithreading
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Sun Jun 17 2001 - 03:20:46 EEST
On Saturday 16 June 2001 19:08, you wrote:
> Benno Senoner wrote:
> >Hello,
> >I've seen this on slashdot:
> >http://www.systemlogic.net/articles/01/6/multithreading/
> >I've not had the time to read it yet but judging from the index it seems
> >interesting and I think it's a good read for us audio folks.
>
> I read it, but it is mostly about *hardware support* for multithreading.
> For those of us that crave acronyms it's about CMP, CMT, FMT etc. ; )
> It is really a good read (especially the slipstream technique seems very
> ingenious).
>
> But it doesn't help us audio folks in coding nice featureful and low
> latency audio apps I'm afraid...
Yes, I should have read it before posing the URL
:-).
Anyway I think it gives us a nice view about what multithreaded/
multiprocessing models we will have to support in our audio apps.
For example the finegrained multithreading model would probably work very
well for lowlatency apps.
Assuming that the threads are really scheduled in the way described in the
paper (a context switch every few machine instructions).
But of course in the realworld there are other issues like the presence of
the opearating system etc.
>
> ....Unless someone implements some technique described in this article (I
> forgot the acronym :) to automagically extract threads from single
> threaded code. Then we could toss multithreading overboard and start
> coding giant balls of single threaded mud :).
Although this can help, I don't think that this can match the human
capabilities of splitting algorithms in separate threads.
I think this is more useful for localized stuff (eg two non dependent loops
that are close in the program flow), but for the best scalability
handtuned multithreading will still be superiour to that one for some time.
Conclusion: if you are planning to make a high performance audio app (eg you
are going to need lots of CPU time), always design it with multithreading in
mind. This allow your app to scale when run on multiprocessor boxes.
The drawback is that often designing a scalable multithreaded app is far from
trivial, especially when you stuff (eg audio processing) that is not easily
parallelizable.
For example running audio processing nets efficiently (aka a typical virtual
studio setup), on multiprocessor hardware is far from trivial.
(and often the nature of the graph hinders us to fully exploit the CPU power
of your N processor machine, even in presence of efficient parallelization
schemes)
Benno.
This archive was generated by hypermail 2b28 : Sun Jun 17 2001 - 03:16:40 EEST