poly~ enable 0 increases CPU instead of decreasing — multithreading explanation?
Hi everyone,
I ran into something weird with poly~ and I can't fully explain it.
I wrapped a heavy subpatcher (groove~, FluCoMa objects, AUReverb2) inside [poly~ compex_sampler.maxpat 1]. When I enable it, DSP Status shows ~13% CPU. When I disable it with enable 0, it jumps to ~33%.
I'm on a Mac Studio. My guess is that poly~ spreads the load across multiple cores, so the DSP monitor (which maybe only reads the main audio thread?) shows less. Disabling it collapses everything back onto one thread.
Is that the right explanation? Is DSP Status only showing one thread?
Thanks
There's an overhead to using multithreading so unless you're doing something where parallelization is beneficial, you can often make things worse (as you're seeing here).
Unfortunately, for audio-based tasks (that aren't a DAW), you're better off on a single thread.
Thanks Rodrigo, that makes total sense. I tested the patch on both my Mac Studio and an old iMac 2012 i5 and the CPU readings were almost identical which confirms exactly what you're saying. The bottleneck is the single audio thread, not total CPU power, so the 17-year hardware gap doesn't really show up here.
p.s I just wanted to find a way to optimize this situation
But since, even if it takes about 5 minutes to start on a 2012 iMac, it runs very smoothly afterwards, I shouldn’t worry about distribution.
I’ll take this opportunity to ask another question: by consolidating the project with its dependencies, I noticed that all the FluCoMa objects are included as externals, so there shouldn’t be any issues for a future standalone version, right?
Appreciate the clarification!
Thanks emiliano!
interesting find, but why in the first place you are using "enable 0" with poly~?
Hi, and thanks for your reply. I wouldn’t really know what to use to manage the CPU in an alternative way :) it’s not something I’m very skilled in.
@roman: My live setup uses about ten different instruments, many of which are quite CPU-intensive. Since I am usually only using two or three at a time, I have them all wrapped in one-instance poly~s to keep down my overhead. So that's one reason, although from looking at Emiliano's patch, I don't see so many opportunities for that particular application....
\M
i am not saying that it would make a difference in your situation, but the more well established method to turn of DSP in a poly~ is "target 0, mute 1" -> [thispoly~]
data rate will still be compiled here, in case it matters.
Thanks everyone for the insights.
I ran a few stress tests and optimized a couple of gen modules, and now the patch runs much more efficiently.
Interestingly, it’s now working smoothly even on my old early 2012 iMac running Mojave, so in my case the bottleneck probably wasn’t multithreading itself, but how the load was structured inside the patch.
thanks again!