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 <i...@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@lists.iem.at
>> https://lists.puredata.info/listinfo/pd-dev
>
>
>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
_______________________________________________
Pd-dev mailing list
Pd-dev@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@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
_______________________________________________
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
