Jonatan Ewald

I know that there are some threads touching upon this, but none that I found seems to give too many answers so I will give it another try;

How can I arrange my patches so that the CPU load gets spread as evenly as possible over all CPU cores in my system?

I saw that the poly~ object seems to have something for this. Does that mean that I can run each voice on a separate CPU core?

If I have more cores than voices can I then still spread the load so that one voice uses 2 cores?

Can I get a 10 core intel i7 CPU and use the full processing power in Max or maybe even a Xeon with 22 cores?

What are the limitations, is it possible to setup so that Max uses all the available processing power dynamically and if not are there any workarounds or smart ways to program so that all CPU cores gets used?

Hi,
I know that there are some threads touching upon this, but none that I found seems to give too many answers so I will give it another try;
How can I arrange my patches so that the CPU load gets spread as evenly as possible over all CPU cores in my system?
I saw that the poly~ object seems to have something for this. Does that mean that I can run each voice on a separate  CPU core?
If I have more cores than voices can I then still spread the load so that one voice uses 2 cores?
How many cores does Max support?
Can I get a 10 core intel i7 CPU and use the full processing power in Max or maybe even a Xeon with 22 cores?
What are the limitations, is it possible to setup so that Max uses all the available processing power dynamically and if not are there any workarounds or smart ways to program so that all CPU cores gets used?

how-to-configure-max-for-multi-core-cpu-use

I can't answer very well as I don't know but you mention poly~ and I was just using it and monitoring CPU loads and found something.

Look to poly help file and click on the multithreading tab.

You can use paralell processing and "Set the number of threads used to divide poly~ instances' audio processing" this does help CPU utilisation.

As far as I have read, i have not seen options to 'make use of cores' but you can control the number of threads that poly use and the threads are what gets used by each core, If you have 4 cores and 2 threads per core then thats 8 threads that could be use. But, i haven't tried making use of it yet - hopefully someone can show a good example of this in action

I can't answer very well as I don't know but you mention poly~ and I was just using it and monitoring CPU loads and found something.
Look to poly help file and click on the multithreading tab.

As far as I have read, i have not seen options to 'make use of cores' but you can control the number of threads that poly use and the threads are what gets used by each core, If you have 4 cores and 2 threads per core then thats 8 threads that could be use. But, i haven't tried making use of it yet - hopefully someone can show a good example of this in action


the poly~ tutorials talks about multi threading somewhere I think?

I guess I need to read up on how poly works in more detail then.

Is it possible to run multiple instances of different subpatches in poly~ and in that way use multiple threads for different processing, or is it mainly used for duplicating one task such as adding additional voices of the same sound?

Is there any kind of generic setup of Max so it utilizes the available processing power in the most efficient way or is poly~ the only way to go?

Is there any way of managing the CPU cores so that I can control what core is used for what?

The last item is not really important to me other than that I see a lot of time only one or two cores are actually used while the others run on idle and it would then be nice to be able to force some processes to one of the cores that are hardly ever used.

Thanks for the reply.
I guess I need to read up on how poly works in more detail then.

Is there any way of managing the CPU cores so that I can control what core is used for what?
The last item is not really important to me other than that I see a lot of time only one or two cores are actually used while the others run on idle and it would then be nice to be able to force some processes to one of the cores that are hardly ever used.


To really make a super program that is totally dedicated to do doing what you want it do, well, probably want to stop using a normal operating system. You probably would write your own operating system dedicated to doing specific tasks only. Then you may as-well make hardware DSP's.

but, there is a lot of power in max and you can make stuff that isnt there in C/Gen for example. but I'm a noob. What are you making?

With poly~, this is the most understanding I have so far:

Set how many threads to use for dividing poly~ instances.

I have to look outside of max to understand what multi-cpu actually and how it works with threads . Threads run the processes, the OS divides the threads I am guessing, to try and evenly distribute its 'Load'. I guess dividing instances of poly attempts to do that.?

Sure there is a way of driving youre load to the max, i don't know of any prebuild object but with poly in specific maybe just load like 1000000 voices and see what happens ?

I loaded 2500 voices as a tester, it took a little bit of time, i then sent a midi note to all voices and my speakers screamed in horror.

To really make a super program that is totally dedicated to do doing what you want it do, well, probably want to stop using a normal operating system. You probably would write your own operating system dedicated to doing specific tasks only.  Then you may as-well make hardware DSP's.
but, there is a lot of power in max and you can make stuff that isnt there in C/Gen for example. but I'm a noob. What are you making?

With poly~, this is the most understanding I have so far:
Enable parallel processing.
Set how many threads to use for dividing poly~ instances.
I have to look outside of max to understand what multi-cpu actually and how it works with threads . Threads run the processes, the OS divides the threads I am guessing, to try and evenly distribute its 'Load'. I guess dividing instances of poly attempts to do that.?
Sure there is a way of driving youre load to the max, i don't know of any prebuild object but with poly in specific maybe just load like 1000000 voices and see what happens ?

edit/warning:
I loaded 2500 voices as a tester, it took a little bit of time, i then sent a midi note to all voices  and my speakers screamed in horror.


Threading in Max, video from cycling74!
https://youtu.be/7n-sl687tkI

But that video basically stated that there are 3 threads (main, scheduler, audio).

If I have a processor with 8 cores, how do I then spread my calculations over all the cores in an efficient way for a real-time response?

Thanks Ben!
That was really helpful!
But that video basically stated that there are 3 threads (main, scheduler, audio).
If I have a processor with 8 cores, how do I then spread my calculations over all the cores in an efficient way for a real-time response?


Jonathan (or anyone else for that matter) ... did you ever find out if you can take full advantage of all cores with Max?

Each instance of a poly~ object is spread across all the available cores. 

For audio, each top level Max patch is processed on a different thread.

If you have SIAI (Scheduler in Audio Interrupt) turned on, then regular events will also have a separate thread.

For audio, each top level Max patch is processed on a different thread.
If you have SIAI (Scheduler in Audio Interrupt) turned on, then regular events will also have a separate thread.

As discussed in the threading video B.T. shared: 

a patch has three threads (main, scheduler and audio).

BUT threads are not CPU cores. So there are a few questions arising in my head:

1. Do I understand it correctly that the three threads of one patch are running on one core? (are there exceptions?)

2. Is each top level Max patch running on a different core? ...or else what do you actually mean by "processed on a different thread" Pedro?

One observation: If you export multiple standalone applications from Max and run them simultaneously they are processed on different CPU cores. If those applications communicate via UDP-send/-receive this could be a workaround to distribute the work load to different cores (that I would prefer not to use).

Does anyone have some deeper insight in how to distribute evenly on all CPU cores? Poly~ is not a solution for everything...

@Pedro Santos
As discussed in the threading video B.T. shared: 
a patch has three threads (main, scheduler and audio).
BUT threads are not CPU cores.  So there are a few questions arising in my head:

1. Do I understand it correctly that the three threads of one patch are running on one core? (are there exceptions?)
2. Is each top level Max patch running on a different core? ...or else what do you actually mean  by "processed on a different thread" Pedro?

One observation: If you export multiple standalone applications from Max and run them simultaneously they are processed on different CPU cores. If those applications communicate via UDP-send/-receive this could be a workaround to distribute the work load to different cores (that I would prefer not to use).

it's sad (and annoying) that this very important question has been hanging here for the past 3 years without an answer

"If you export multiple standalone applications from Max and run them simultaneously they are processed on different CPU cores "

yes, or like pedro pointed out above, seperate patcher windows in the same runtime.

so even in a standalone later you could open 3 invisible, special patchers via pcontrol and do some s/r there for running the reverbs or vst plug-ins or whatever.

this is not elegant, but still better than using poly~.


"If you export multiple standalone applications from Max and run them simultaneously they are processed on different CPU cores "

yes, or like pedro pointed out above, seperate patcher windows in the same runtime.

so even in a standalone later you could open 3 invisible, special patchers via pcontrol and do some s/r there for running the reverbs or vst plug-ins or whatever.

this is not elegant, but still better than using poly~.


How about management of threads PER patcher window? Say I have an audiovisual patch which includes a ton of msp, jitter and max operations (not to mention drawing of the number boxes etc. GUI calculations(?))

Are all these calculations handled by one core alone? I'd be more than happy if someone from the staff could answer this question.

How about management of threads PER patcher window? Say I have an audiovisual patch which includes a ton of msp, jitter and max operations (not to mention drawing of the number boxes etc. GUI calculations(?))

Are all these calculations handled by one core alone? I'd be more than happy if someone from the staff could answer this question.

Toothpaste, the standard solution if you have, say, two large patches, is to launch Max twice. It will be allocated to different cores by the OS.

It's basically what Roman and others said, except you don't have to make a Standalone. That will save you headaches, and memory space.

On Mac, to launch an app a second time, you can use the Terminal and use the -n flag:

Toothpaste, the standard solution if you have, say, two large patches, is to launch Max twice. It will be allocated to different cores by the OS.
It's basically what Roman and others said, except you don't have to make a Standalone. That will save you headaches, and memory space.
On Mac, to launch an app a second time, you can use the Terminal and use the -n flag:
open -n /Applications/Max\ 8.app

Thanks for your answer Jean-Francois. A big inconvenience for me but still a workaround!

It is still not clear as to how max handles distribution of computational load across the cores.

Are you saying that I need to start two different instances of Max in order to make use of multiple cores? So, even having two separate patchers is not enough? Because what Roman and Pablo suggested sounds like one can already utilize two cores by running two patchers within one instance of Max

Thanks for your answer Jean-Francois. A big inconvenience for me but still a workaround!

It is still not clear as to how max handles distribution of computational load across the cores.
Are you saying that I need to start two different instances of Max in order to make use of multiple cores? So, even having two separate patchers is not enough? Because what Roman and Pablo suggested sounds like one can already utilize two cores by running two patchers within one instance of Max







"Are you saying that I need to start two different instances of Max in order to make use of multiple cores?"

You don't "need" to, but it's a reliable solution.

"having two separate patchers is not enough?": Pedro mentioned that the Audio part of separate top-level patchers are processed on separate threads, not the scheduler nor the low-priority data.

You can try to use the multi-core capabilities of poly~, but:

- that might be quite some work to convert / adapt your patches.

- you might gain some power by splitting some work across cores, but you might loose some because that splitting has to be managed, with some communication between the threads to take care of. That cost might or not be negligible compared to the processing cost of the poly~ voice itself.

- poly~ will split the work in separate threads, it's not guaranteed that it's processed on different cores. The OS will choose on which core to process the thread.

- that, I'm not sure, but I suspect that parallel in poly~ will only split the DSP into separate threads. The data processing (and CPU Jitter) will be stuck on one core anyway. Don't take my word for that: I hope someone here with more experience can con/in-firm.

When you open Max several times (same as "making several standalones", but more direct), you just need to remember that you can't communicate from one instance to the other with patch cables nor send/receive pairs: you have to use something like OSC, MIDI, audio signals, etc.

Note that even when you open Max several times (or use separate standalones), the OS will choose where to run them depending on what's best at the given time (often, it will be on different cores).

I mentioned this solution because I've met a number of seasoned users over the years, who have used it successfully.

"Are you saying that I need to start two different instances of Max in order to make use of multiple cores?"
You don't "need" to, but it's a reliable solution.

"having two separate patchers is not enough?": Pedro mentioned that the Audio part of separate top-level patchers are processed on separate threads, not the scheduler nor the low-priority data.
You can try to use the multi-core capabilities of poly~, but:
- that might be quite some work to convert / adapt your patches.
- you might gain some power by splitting some work across cores, but you might loose some because that splitting has to be managed, with some communication between the threads to take care of. That cost might or not be negligible compared to the processing cost of the poly~ voice itself.
- poly~ will split the work in separate threads, it's not guaranteed that it's processed on different cores. The OS will choose on which core to process the thread.
- that, I'm not sure, but I suspect that parallel in poly~ will only split the DSP into separate threads. The data processing (and CPU Jitter) will be stuck on one core anyway. Don't take my word for that: I hope someone here with more experience can con/in-firm.

When you open Max several times (same as "making several standalones", but more direct), you just need to remember that you can't communicate from one instance to the other with patch cables nor send/receive pairs: you have to use something like OSC, MIDI, audio signals, etc. 

in 99% of the cases distributing DSP to other cores is all you need.

adobe photoshop also only uses all cores for plug-ins, built-in image filters and mpeg/jpeg export, but not for dropdownmenus, file dialogs or for receiving a mouseclick.

and the more DSP is moved to extra cores, the more CPU is present for scheduler, runtime and OS tasks on the first core. 

if i havent missed something, this will already work:

grafik.png


in 99% of the cases distributing DSP to other cores is all you need.

adobe photoshop also only uses all cores for plug-ins, built-in image filters and mpeg/jpeg export, but not for dropdownmenus, file dialogs or for receiving a mouseclick.

and the more DSP is moved to extra cores, the more CPU is present for scheduler, runtime and OS tasks on the first core. 

if i havent missed something, this will already work:

I tried Roman‘s solution with pcontrol. Processor running at around 30% or higher cpu.

i tried Jean-Francois solutio with multiple standalones. same result.

then I tried opening half of the patch in one instance of Max, and using “open -n -a Max 8111” I opened the other half of the patch- each instance is running at about 13-15% cpu.

however. I cannot find a single object that will pass audio between instances. I can get udpsend/ revieve to work for sending messages, or even better spat5udspend,—- jit.net will not send audio. send~ receive~ does not seem to work between instances.

I really need to split up the audio processing. 

delay time for sending doesn’t really matter.

there is no wired overlap in what I have built. I have 4 separate patches each doing something unique and different. 

Input is patch 1. I can play through that and unprocessed sound is out put to my system.

Record/play is a patch 2 and receives audio from Input. These should both run in the first instance.

Surround is patch 3 and receives audio from the record/play patch. This is where I want to start the second instance of max.

Then a small output/record in a final patch.

so long story shortened- how do I send audio between separate instances of Max (after reading the past 15 years of threads nothing seems to work)?

So I recently did this experiment. 
I tried Roman‘s solution with pcontrol. Processor running at around 30% or higher cpu.
i tried Jean-Francois solutio with multiple standalones. same result.
then I tried opening half of the patch in one instance of Max, and using “open -n -a Max 8111” I opened the other half of the patch- each instance is running at about 13-15% cpu.

however. I cannot find a single object that will pass audio between instances. I can get udpsend/ revieve to work for sending messages, or even better spat5udspend,—- jit.net will not send audio. send~ receive~ does not seem to work between instances.

I really need to split up the audio processing.  
delay time for sending doesn’t really matter.

there is no wired overlap in what I have built. I have 4 separate patches each doing something unique and different.  
Input is patch 1. I can play through that and unprocessed sound is out put to my system.
Record/play is a patch 2 and receives audio from Input. These should both run in the first instance.
Surround is patch 3 and receives audio from the record/play  patch. This is where I want to start the second instance of max.
Then a small output/record in a final patch.

so long story shortened- how do I send audio between separate instances of Max (after reading the past 15 years of threads nothing seems to work)?



You can use Rogue Amoeba’s Loopback or Soundflower to send audio from one instance of Max to another. Also, the thread below might apply just as well to inter-application audio communication...

Hmmm, forum prevented my link. Search for ”piping audio between macs” or see my posts.

Adding to the thread, because there's still not much about multithreading out there.

Using Max 8.5.4, the only reliable way of using all the cores I found is to use Roman's method of starting independent patchers and using send/receive between them.

The poly~ approach didn't work for me (but I haven't explored it much)

Adding to the thread, because there's still not much about multithreading out there. 

Using Max 8.5.4, the only reliable way of using all the cores I found is to use Roman's method of starting independent patchers and using send/receive between them. 

How to configure Max for multi core CPU use?