[Sharing is a Process]: CPU core use and multiple top level patches in OSx 10.9
Hello,
I've been looking into Max 6.1.7 audio performance under OSx 10.9+ ("Mavericks"). The system I am using is a Mac Pro generation 3,1 with 8 3Ghz Xeon cores and 16 GB RAM using 2 Focusrite Saffire 40 firewire interfaces in "dual-unit" mode.
Cycling 74 describes Max 6 audio this way:
We now run the audio of every top-level patcher in its own thread for effortless multicore processing
Just so happens I have an audio system created with MaxMSP that processes 16 channels of realtime audio in and out. When I designed it I created 2 versions:
All the MSP processing occurs in one patch
32 separate patches (one for each input and output)
I used version 2 exclusively on the system under OSx 10.6.8, with great success.
I recently upgraded the Mac Pro 3,1 to OSx 10.9.4. Apple's own description of process management and some other experiences with audio under OSx 10.9 made me want to check and see how Max 6 and OSx 10.9 performance enhancements worked together. The images show Activity Monitor CPU History samples of several minutes time, with MSP audio enabled. Top is a system with a 32 top-level patches, one for each channel of audio in and out. Bottom is using a Max patch where all audio processing occurs in a single patch.
Based on these graphs I think that, under OSx 10.9+, it's preferable to put MSP processes in a single patch (or as few patches as possible).
Is this correct?
Bump
interesting question indeed
If anyone returns here I have noticed that the multiple top level patchers solution does increase efficiency when each top level patch has a lot of processing going on (like convolution or other algorithmic type processes).
I would modify my earlier idea:
Based on these graphs I think that, under OSx 10.9+, it’s preferable to put MSP processes in a single patch (or as few patches as possible).
to suggest that the improvement in efficiency using multiple top level patchers is negligible when each patch is doing a little work, but a deciding factor when the overall system is processing a lot of audio.
I like when users are almost talking to themselves and still keep on reporting on the situation.
It might seem the work is not being appreciated, but there will come a time when it will certainly be useful to someone. So, thanks for the update!
Now, regarding the subject, instead of the multi-patch approach, have you tried to encapsulate all the patches in a poly~ object with "parallel 1"?
Pedro,
Poly~ is not appropriate for the patch I'm talking about here.
Regarding poly~ @parallel 1 look here:https://cycling74.com/forums/feature-request-expanding-the-scope-of-parallel-processing/
For me testing has indicated that there's no one "best" way to leverage CPU resources for MSP audio. Changing the "Enable Mixer Parallel Processing" preference can make a big difference in problematic patches.
It's sometimes better to use a single core for all audio, sometimes better to multithread. Just gotta try.