On Apr 6, 2011, at 2:52 PM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2011-04-06 20:26, Hans-Christoph Steiner wrote:
Pd has its own scheduling system which is best to stick to as long as
you can so that you can keep the deterministic operation intact. For
convolution, I can't see a reason to use a thread. It adds
complexity
and more code to run, but if the CPU is overtaxed by realtime
convolution processing, you are going to get an interruption in the
audio regardless of whether the processing is in a thread or not.
partioned convolutions can gain massively from parallelisation.
given that we have more and more CPUs available, i think it is a good
thing to try and do a multicore convolution.
otoh, if there is only a single thread doing the convolution, then
there
is no parallelisation, and thus the only thing gained is complexity.
using "threats" does not mean that things have to get non-
deterministic,
and indeed a lot of software uses threads and stays completely
deterministic.
Yes, you can make things deterministic using threads. Coding without
threads, its basically automatically deterministic, but when using
threads, you have to code things right to have it deterministic.
Having multiple threads to support multiple cores definitely makes
sense, so I guess this multi-threaded pd object would just need to
wait for the results of all threads before letting the DSP tick
complete, thereby ensuring deterministic behavior.
.hc
----------------------------------------------------------------------------
Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war on
terrorism. - retired U.S. Army general, William Odom
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
