Jpunt

https://cycling74.com/forums/index.php?t=msg&goto=165385&rid=0

 I'm working on an interactive installation that includes multiple camera's, effects, recording and layering of video. Because this could become a quite intense process (even though I'm now using opengl for some stuff), i'm researching some performance-options/opportunities. 

As seejayjames pointed out I should look at poly~, but this seems to be audio-only. I know that the upcoming OSX does this core-task-separation automatically, so I wanted to compare some things. But looking at my current running patch, it seems to be already divided between the cores! I use MenuMeters to display the stats of both my cores and those give more or less the same numbers. 

Is this correct? Or if this couldn't be possible, does anyone know how to monitor the exact processes for every core, for this particular application?

as sad in this thread: https://cycling74.com/forums/index.php?t=msg&goto=165385&rid=0 I'm working on an interactive installation that includes multiple camera's, effects, recording and layering of video. Because this could become a quite intense process (even though I'm now using opengl for some stuff), i'm researching some performance-options/opportunities. 
As seejayjames pointed out I should look at poly~, but this seems to be audio-only. I know that the upcoming OSX does this core-task-separation automatically, so I wanted to compare some things. But looking at my current running patch, it seems to be already divided between the cores! I use MenuMeters to display the stats of both my cores and those give more or less the same numbers. 
Is this correct? Or if this couldn't be possible, does anyone know how to monitor the exact processes for every core, for this particular application?

multicore-processes-on-mac-10-5-10-6

poly~ is not just for audio. Have a look at the example "Poly~ForMovies.maxpat" (in the jitter-examples).

Another option to take advantage of multicores is to run Max several times (2 different standalones, for instance).

poly~ is not just for audio. Have a look at the example "Poly~ForMovies.maxpat" (in the jitter-examples).
Another option to take advantage of multicores is to run Max several times (2 different standalones, for instance).
Jean-Francois.


ah great! I'll totally missed this, so I'll look into it. Any tips on monitoring these multicore processes?

Jean-Francois Charles wrote on Fri, 20 February 2009 15:27

poly~ is not just for audio. Have a look at the example "Poly~ForMovies.maxpat" (in the jitter-examples)

 although only DSP processing can take advantage of the multi processing. Most of the jitter objects already take advantage of multi cores without doing anything specific since version 1.5. And as Jean-François mentioned, running multiple standalone on the machine might give you even better performances.

On MacOS you can monitor CPU utilization using CPU Monitor.

Jean-Francois Charles wrote on Fri, 20 February 2009 15:27poly~ is not just for audio. Have a look at the example "Poly~ForMovies.maxpat" (in the jitter-examples)

Right you can do any kind of things in poly~ although only DSP processing can take advantage of the multi processing. Most of the jitter objects already take advantage of multi cores without doing anything specific since version 1.5. And as Jean-François mentioned, running multiple standalone on the machine might give you even better performances.

 although only DSP processing can take advantage of the multi processing. Most of the jitter objects already take advantage of multi cores without doing anything specific since version 1.5.

That's good to know, I was a bit unclear about that. So jitter would automatically play two simultaneous movies, say, using each core? Wondering whether one can specify how this all happens. Would be great to have a "use second core" flag in particular objects, so they would utilize it if possible, or specify that you don't want them to use it (for whatever reason). Maybe this is difficult to implement though.

Right you can do any kind of things in poly~ although only DSP processing can take advantage of the multi processing. Most of the jitter objects already take advantage of multi cores without doing anything specific since version 1.5. 

seejayjames wrote on Mon, 23 February 2009 02:00

That's good to know, I was a bit unclear about that. So jitter would automatically play two simultaneous movies, say, using each core?

It's done under the hood automatically and you don't have much control over it. That's the way it works on current operating system. There's a few 

 to enable/disable parallel processing as well as the number of thread used.

Wondering whether one can specify how this all happens. Would be great to have a "use second core" flag in particular objects, so they would utilize it if possible, or specify that you don't want them to use it (for whatever reason). Maybe this is difficult to implement though.

seejayjames wrote on Mon, 23 February 2009 02:00
That's good to know, I was a bit unclear about that. So jitter would automatically play two simultaneous movies, say, using each core? 

It's done under the hood automatically and you don't have much control over it. That's the way it works on current operating system. There's a few messages to enable/disable parallel processing as well as the number of thread used.

Quote:
Wondering whether one can specify how this all happens. Would be great to have a "use second core" flag in particular objects, so they would utilize it if possible, or specify that you don't want them to use it (for whatever reason). Maybe this is difficult to implement though.

Emmanuel Jourdan wrote on Sun, 22 February 2009 07:56Jean-Francois Charles wrote on Fri, 20 February 2009 15:27

 although only DSP processing can take advantage of the multi processing.

There are a pair of objects on the CNMAT site called thread.fork and thread.join that let you take advantage of multi-core in the Max domain. They're pretty new; I hope they work well.

Emmanuel Jourdan wrote on Sun, 22 February 2009 07:56Jean-Francois Charles wrote on Fri, 20 February 2009 15:27poly~ is not just for audio. Have a look at the example "Poly~ForMovies.maxpat" (in the jitter-examples)

Right you can do any kind of things in poly~ although only DSP processing can take advantage of the multi processing. 

There are a pair of objects on the CNMAT site called thread.fork and thread.join that let you take advantage of multi-core in the Max domain.  They're pretty new; I hope they work well.

Thanks ej, your info and Joshua's post helped clear a lot of things up. One quick question: if using the multi-app-open-simultaneously approach, is there any advantage to using jit.net.send/recv versus standard send and receive for matrices? Wondering if one way is faster than the other.

seejayjames wrote on Tue, 24 February 2009 01:17

One quick question: if using the multi-app-open-simultaneously approach, is there any advantage to using jit.net.send/recv versus standard send and receive for matrices? Wondering if one way is faster than the other.

Multiple open app can only communicate via network protocols. Simple send/receive won't work.

seejayjames wrote on Tue, 24 February 2009 01:17One quick question: if using the multi-app-open-simultaneously approach, is there any advantage to using jit.net.send/recv versus standard send and receive for matrices? Wondering if one way is faster than the other.

Multiple open app can only communicate via network protocols. Simple send/receive won't work.


Emmanuel Jourdan wrote on Mon, 23 February 2009 18:31seejayjames wrote on Tue, 24 February 2009 01:17

Ah, guess I had assumed that any open patch would have send and receive available. So it's any open patch *per application* that can have its own send and receive, interesting. Always something more to learn, thanks!

Emmanuel Jourdan wrote on Mon, 23 February 2009 18:31seejayjames wrote on Tue, 24 February 2009 01:17One quick question: if using the multi-app-open-simultaneously approach, is there any advantage to using jit.net.send/recv versus standard send and receive for matrices? Wondering if one way is faster than the other.

Ah, guess I had assumed that any open patch would have send and receive available. So it's any open patch *per application* that can have its own send and receive, interesting. Always something more to learn, thanks!


Multicore Processes (on Mac 10.5 / 10.6)