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

[Christof Ressi]

> This has nothing to do with callback mode, as such. it is a general 
> performance note included to illustrate the various things that I 
> discovered, often with much debugging of PD itself, which affect 
> performance.
Ok, I see. Note that *receiving* messages is more or less fine because 
the I/O happens with select() and therefore essentially non-blocking. 
The problem is *sending* messages. The proper solution is to move 
network I/O to a dedicated thread 
(https://github.com/pure-data/pure-data/pull/1261), but I guess one 
could mitigate the problem by increasing the socket send buffer size, so 
that send() is less likely to block.

  --

> yet you tell me that the main remedy is to increase lag?
The main remedy is to get a better computer :) Most importantly, a CPU 
with strong single-thread performance and good ventilation to prevent 
throttling. Also, make sure to set the energy manager to highest 
performance.

Many users (including myself) manage to run Pd with latencies below 10ms 
- which I would consider suitable for live performance. I was mainly 
questioning your claim that you cannot get a clean output with the 
polling mode *at all*.

That being said, the current polling mode implementation *does* have a 
few problems - which I am trying to address with 
https://github.com/pure-data/pure-data/pull/1756.

--

> The most effective single change was the change to [pd~]
Again, this just adds another layer of buffering. I am not surprised 
that you see more stable performance, but you should get the same effect 
with the polling scheduler. Please try my scheduler-fix branch above!

--

> Running the audio DSP in an execution context separate from UI 
> messaging seems to me to be a crucial performance improvement for PD. 
> My experience with [pd~] certainly shows that. I would hope that a 
> separately threaded DSP engine would do the same.
Multi-threaded DSP only lets you distribute the *DSP* CPU load over 
several cores. It does not affect CPU spikes caused by messaging or I/O 
operations. While the latter *can* be moved to dedicated threads, Pd 
messages always execute in the same thread as DSP by design; 
multi-threaded DSP does not change that. The idea of the polling 
scheduler is that you add some additional buffering to "absorb" CPU 
spikes caused by the messaging system. The required delay really depends 
on the patch in question and the system in general.

Now, you *can* also use the callback scheduler with a large enough 
"block size" (= hardware buffer size) instead, but you are limited to 
power-of-two values. For example, if 512 samples just does not cut it, 
you are forced to move to 1024; there is no room in between. With the 
polling scheduler, however, you can set the delay at a much finer 
granularity. Typically, you would set the "block size" to the lowest 
possible value (with a good machine and audio interface, 64 samples 
should be possible), and then adjust the "delay" as necessary.

Christof

On 24.08.2023 16:48, Day Rush wrote:
> On Thu, 24 Aug 2023 at 14:12, Christof Ressi <info at christofressi.com> 
> wrote:
>
>>     Perhaps. But I was definitely able to manually bump the priority
>>     without sudo. 
>     I don't doubt that you can manually bump the priority; that
>     doesn't necessarily mean that Pd itself can do it.
>
>     BTW, if Pd fails to raise the thread priority to RT, you should
>     get the following error message in the Pd console:
>
>     "priority %d scheduling failed; running at normal priority"
>
> I don't recall seeing that on the console, but I may have seen it on 
> stdout once or twice.
>
>>     1 - the PD UI will absolutely kill performance
>     The Pd GUI runs as a separate process with lower priority. If you
>     mean the actual network I/O for core <-> GUI communication, then I
>     don't see how running Pd in callback mode would improve this - on
>     the contrary!
>
>
> This has nothing to do with callback mode, as such. it is a general 
> performance note included to illustrate the various things that I 
> discovered, often with much debugging of PD itself, which affect 
> performance.
>
>>     2 - because of 1, plan to run the sound gen in [pd~]
>
>     In general, it doesn't really make sense to run *all* DSP in
>     [pd~]; instead, just use the standard polling mode and raise
>     "delay" accordingly.
>
> This is a very disappointing answer. I really keep hoping to get away 
> from static composition and move towards live performance, and yet you 
> tell me that the main remedy is to increase lag? Is PD really just 
> CSound with a better sound design workflow?
>
>     It may very well be an issue with your computer/OS. Did you try
>     other machines?
>
> As I said earlier, it was quite an old laptop, and the composition had 
> a lot of physically modelled voices. My Win laptop was unilaterally 
> upgraded to Win11 by u$oft and ceased to perform well at anything 
> other than playing video, so I kind of left it behind. The list I 
> provided gave me nice clean sound. The most effective single change 
> was the change to [pd~]. I will freely grant the possibility that the 
> re-architecture of my program necessary to run in that environment may 
> have improved performance, but that still points to UI (and the 
> attendant clunky communication) issues as being a primary performance 
> problem. Running the audio DSP in an execution context separate from 
> UI messaging seems to me to be a crucial performance improvement for 
> PD. My experience with [pd~] certainly shows that. I would hope that a 
> separately threaded DSP engine would do the same.
>
> _______________________________________________
> 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/20230824/f39e149b/attachment.htm>