Heh. I composed an email this morning proposing a less fine-grained, manual approach to parallelism in Pd, perhaps at the subpatch level with switch~/block~-like control.
I trashed the email, because I figured it was too much to hope for, and I don't understand PD internals well enough to know it it's even feasible. And now to hear it's being thought about in DD...this is so cool! I really hope it can happen. Please keep us posted on any developments. Phil Claude Heiland-Allen wrote: > Phil Stone wrote: >> This has been a fascinating thread about the direction of PD. >> >> I've been thinking about parallelism and PD as multi-core processors >> become common. How hard would it be to make PD able to take >> advantage of parallel architecture? I'm guessing that it is >> decidedly non-trivial, as lack of threading is already an issue in >> contention between the GUI and audio processing. >> >> Without some support for parallelism, PD could be going as fast as it >> will ever go -- the trend seems to be that CPU speeds will not be >> climbing much (at least not dramatically like they have until now), >> and increasing numbers of cores will be the path to greater speed and >> power. >> Is there any hope in this direction? >> >> >> Phil Stone > > I had a discussion with matju in #dataflow [1] last week about > possible directions for multithreading in Pd. The general conclusions > we reached were roughly: > > 1. threading/parallelism is necessary, and will become more necessary > > 2. trying to automatically split the computational load between > multiple threads will be very difficult and the result sub-optimal > > 3. solution: a primitive in Pd for manually controlled threading > > 4. the existing threading externals are error prone, because you need > object delimiters at all boundaries of the non-specific region to be > threaded, otherwise horrible crashes can result > > 5. methods already exist in Pd for defining specific regions, namely > abstractions and subpatches > > 6. there are already objects that change the properties of those > specific regions, namely [block~] and [switch~] > > 7. a similar object could be created to make a specific region a > separate thread, which would change the behaviour of [inlet] [outlet] > etc to communicate between threads, much like [block~] changes the > behaviour of [inlet~] etc to communicate between different signal > vector block sizes. > > 8. arguments and messages to the [thread] object (or however it is > named) could adjust the thread priority, or other parameters. > > > Claude > > [1] irc://irc.freenode.net/#dataflow > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
