[PD-dev] why must one never send a message from a perform routine ?

[Christof Ressi]

> How well does it work?
It seems to work quite well. With synthetic benchmarks I can get a 6x 
speedup on my 8 core machine, but I need to do some more practical 
testing and benchmarking.

> It looks like the repo is based off of 0.52?
I think it's based on 0.53. I want to rebase it on 0.54, but there are 
lots of conflicts I need to resolve. It's definitely on my TODO list. 
That's also why I haven't really made a formal announcement yet.

> Multithreaded DSP would have been much higher on my list than 
> multi-channel,
Priorities are very subjective. Personally, I don't really think that 
multithreaded DSP has high priority for the general user base, as many 
patches seem to run fine on a single CPU. However, I do have projects 
that reach or exceed the limits of a single CPU - even on a beefy 
machine -, that's why I started working on this.

> so I'm wondering if I could get away with using your tree as my basis 
> for a while :)
Actually, it would be great to have some testers apart from myself!

Christof

On 22.08.2023 10:32, Day Rush wrote:
> How well does it work? It looks like the repo is based off of 0.52? 
> Multithreaded DSP would have been much higher on my list than 
> multi-channel, so I'm wondering if I could get away with using your 
> tree as my basis for a while :)
>
> - d
>
> On Tue, 22 Aug 2023 at 01:17, Christof Ressi <info at christofressi.com> 
> wrote:
>
>     To expand on Miller's reply:
>
>     Conceptually, messaging and DSP are two separate domains. Sending a
>     message from a perform routine violates this separation. Instead you
>     should use a clock with delay 0 to defer the message to the begin
>     of the
>     next scheduler tick.
>
>     Miller already mentioned the greatest danger, but there are other,
>     more
>     subtle issues. DSP objects typically operate on the premise that the
>     object's state won't change from the outside during the perform
>     routine.
>     For example, imagine a delay object with a buffer that can be resized
>     with a message; by sending a Pd message from the perform routine, it
>     might accidentally feed back into the object and reallocate the
>     buffer
>     while still in progress.
>
>     Unfortunately, very little of this is documented. Ideally, this
>     should
>     be covered in the externals-how-to
>     (https://github.com/pure-data/externals-howto); I just added an
>     item on
>     my (long) TODO list.
>
>     Finally, although Pd is currently single-threaded, this could
>     change in
>     the future. FWIW, here is a PoC for multi-threaded DSP:
>     https://github.com/spacechild1/pure-data/tree/multi-threading.
>     This is
>     only possible because perform routines may only use a restricted
>     set of
>     API functions - which, in my fork, are annoted with the (empty)
>     THREADSAFE macro (and made thread-safe, if necessary).
>
>     Christof
>
>     On 21.08.2023 20:55, Joseph Larralde wrote:
>     > Hmm, I see ... unfortunately my random bug is totally unrelated to
>     > this weakness of my code.
>     > Thanks Miller for the explanation and pointers to examples !
>     > And thanks Claude for the extra example.
>     > I'll check all my objects to see if there are other ones I can
>     > consolidate.
>     >
>     > Cheers !
>     >
>     > Joseph
>     >
>     > Le 21/08/2023 à 19:08, Claude Heiland-Allen a écrit :
>     >> See bang~ in pure-data/src/d_misc.c for an example that uses a
>     clock
>     >> to send a message from DSP.
>     >>
>     >> On 21/08/2023 18:02, Miller Puckette wrote:
>     >>> The built-in objects "delay", "metro" and "pipe" use clocks in
>     >>> various ways.
>     >>>
>     >>> On 8/21/23 18:02, Joseph Larralde wrote:
>     >>>> I just read in an answer from Christof to Alexandre : "never
>     ever
>     >>>> send a Pd message directly from a perform routine ! Always use a
>     >>>> clock !"
>     >>
>     >>
>     >>
>     >>
>     >> _______________________________________________
>     >> Pd-dev mailing list
>     >> Pd-dev at lists.iem.at
>     >> https://lists.puredata.info/listinfo/pd-dev
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > Pd-dev mailing list
>     > Pd-dev at lists.iem.at
>     > https://lists.puredata.info/listinfo/pd-dev
>
>
>
>     _______________________________________________
>     Pd-dev mailing list
>     Pd-dev at lists.iem.at
>     https://lists.puredata.info/listinfo/pd-dev
>
>
>
> -- 
> GPG Public key at http://cyber-rush.org/drr/gpg-public-key.txt
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20230822/675d0697/attachment-0001.htm>