keith@beamfoundation.

I'm running Jitter 1.42 and Max 4.57 on a dual core AMD & Win XP.

So I have a couple of QT movies playing at 15 fps (encoded photo JPEG at 15fps 320 x 240) and some processing and the two cores are running at about 50% for Max and 49% System Idle.

Now when I add more video processing to the exact same movies my frame rate drops to 4 fps but my CPU usage remains the same Max: 50% and System Idle: 49%.

What limits Max/Jitter from using more of the CPU? Any way to open this up to say 70%. MSP is turned off (it's a video only machine) and I have mucked with scheduler settings to no avail.

I'm running Jitter 1.42 and Max 4.57 on a dual core AMD & Win XP. 

Keith McMillen 
BEAM Foundation 
http://www.beamfoundation.org/ 
510.502.5310


how-to-get-beyond-50-cpu-useage-for-jitter

On Aug 21, 2006, at 5:40 PM, Keith McMillen wrote:

> What limits Max/Jitter from using more of the CPU? Any way to open 

> this up to say 70%. MSP is turned off (it's a video only machine) 

> and I have mucked with scheduler settings to no avail.

It really depends on where the bottlenecks in your patch are, as to 

how much advantage there will be to having multiple cores. There's a 

1. It could be the movie decompression. QT on windows doesn't 

necessarily use multiple threads for decompression.

2. Depending on the jitter objects in use, they may not use multiple 

threads. For example, almost all pointwise operators will use 

multiple threads if there are multiple cores (pointwise operators 

include things like jit.charmap, jit.clip, jit.op, jit.xfade, etc.). 

Most spatial operators (with the exception of jit.convolve, have not 

3. It could be memory bandwidth or resources which is the bottleneck. 

(sometimes multi-core processors do not offer any advantages if they 

are consistently contending over the same region of memory)

4. It might be related to VBL synchronization (try disabling 

The only thing you can do to improve your patch without changing it 

would be to disable @sync. If you can change your patch, you might be 

able to speed things up if you disable spatial objects like jit.rota 

or jit.repos which are currenlty single threaded, and perhaps your 

In general I would move all expensive processing to the GPU where 

possible if you really want high performance (2-16x speedups), but 

you might be able to make better advantage of your dual core CPU by 

running two copies of MaxMSP (e.g. use the runtime side by side with 

the std app), where one patch communicates to the other patch via 

jit.net.send/recv on localhost. Since this is a true separate 

process, it can be dispatched by the OS to the second core.

> What limits Max/Jitter from using more of the CPU? Any way to open  
> this up to say 70%. MSP is turned off (it's a video only machine)  
> and I have mucked with scheduler settings to no avail.

It really depends on where the bottlenecks in your patch are, as to  
how much advantage there will be to having multiple cores. There's a  
few things to consider:

1. It could be the movie decompression. QT on windows doesn't  
necessarily use multiple threads for decompression.

2. Depending on the jitter objects in use, they may not use multiple  
threads. For example, almost all pointwise operators will use  
multiple threads if there are multiple cores (pointwise operators  
include things like jit.charmap, jit.clip, jit.op, jit.xfade, etc.).  
Most spatial operators (with the exception of jit.convolve, have not  
been made multiprocessor aware).

3. It could be memory bandwidth or resources which is the bottleneck.  
(sometimes multi-core processors do not offer any advantages if they  
are consistently contending over the same region of memory)

4. It might be related to VBL synchronization (try disabling  
jit.window @sync).

The only thing you can do to improve your patch without changing it  
would be to disable @sync. If you can change your patch, you might be  
able to speed things up if you disable spatial objects like jit.rota  
or jit.repos which are currenlty single threaded, and perhaps your  
bottleneck.

In general I would move all expensive processing to the GPU where  
possible if you really want high performance (2-16x speedups), but  
you might be able to make better advantage of your dual core CPU by  
running two copies of MaxMSP (e.g. use the runtime side by side with  
the std app), where one patch communicates to the other patch via  
jit.net.send/recv on localhost. Since this is a true separate  
process, it can be dispatched by the OS to the second core.

I've doing something similar also on a windows machine (Intel dual core

Anyhoo i think u might profit from downloading Jitter 1.5, since in the

'whats new' document (found on the cycling site >

https://cycling74.com/download/jitter15doc.zip

Jitter 1.5 there's full support for multiprocessoring system.

I get reasonalbe performance and definitely don't get stuck at 50% of my

check it out! think that could do the trick. ( download link:

> I'm running Jitter 1.42 and Max 4.57 on a dual core AMD & Win XP.

> So I have a couple of QT movies playing at 15 fps (encoded photo JPEG at

> 15fps 320 x 240) and some processing and the two cores are running at about

> Now when I add more video processing to the exact same movies my frame

> rate drops to 4 fps but my CPU usage remains the same Max: 50% and System

> What limits Max/Jitter from using more of the CPU? Any way to open this up

> to say 70%. MSP is turned off (it's a video only machine) and I have mucked

I've doing something similar also on a windows machine (Intel dual core
though).
Anyhoo i think u might profit from downloading Jitter 1.5, since in the
'whats new' document (found on the cycling site >
https://cycling74.com/download/jitter15doc.zip ), there's stated that from as
Jitter 1.5 there's full support for multiprocessoring system.
I get reasonalbe performance and definitely don't get stuck at 50% of my
systems maximum...

check it out! think that could do the trick. ( download link:
https://cycling74.com/downloads/jitter )

On 8/22/06, Keith McMillen  wrote:
>
> Hi,
>
> I'm running Jitter 1.42 and Max 4.57 on a dual core AMD & Win XP.
>
> So I have a couple of QT movies playing at 15 fps (encoded photo JPEG at
> 15fps 320 x 240) and some processing and the two cores are running at about
> 50% for Max and 49% System Idle.
>
> Now when I add more video processing to the exact same movies my frame
> rate drops to 4 fps but my CPU usage remains the same Max: 50% and System
> Idle: 49%.
>
> What limits Max/Jitter from using more of the CPU? Any way to open this up
> to say 70%. MSP is turned off (it's a video only machine) and I have mucked
> with scheduler settings to no avail.
>
> Thanks,
>
> Keith
>
>
> Keith McMillen
> BEAM Foundation
> http://www.beamfoundation.org/
> 510.502.5310
>
>
>
>


And also try changing the Max Options > Performance Options, such as 

slop, poll & low priority throttles, etc; it made a suprisingly big 

difference to the max CPU usage on my setup.

On Aug 22, 2006, at 12:56 AM, david vandenbogaerde wrote:

> I've doing something similar also on a windows machine (Intel dual 

> Anyhoo i think u might profit from downloading Jitter 1.5, since in 

> the 'whats new' document (found on the cycling site > 

> cycling74.com/download/jitter15doc.zip ), there's stated that from 

> as Jitter 1.5 there's full support for multiprocessoring system.

> I get reasonalbe performance and definitely don't get stuck at 50% 

> check it out! think that could do the trick. ( download link: 

> So I have a couple of QT movies playing at 15 fps (encoded photo 

> JPEG at 15fps 320 x 240) and some processing and the two cores are 

> running at about 50% for Max and 49% System Idle.

> Now when I add more video processing to the exact same movies my 

> frame rate drops to 4 fps but my CPU usage remains the same Max: 

And also try changing the Max Options > Performance Options, such as  
slop, poll & low priority throttles, etc; it made a suprisingly big  
difference to the max CPU usage on my setup.

> Hi Keith,
>
> I've doing something similar also on a windows machine (Intel dual  
> core though).
> Anyhoo i think u might profit from downloading Jitter 1.5, since in  
> the 'whats new' document (found on the cycling site > http:// 
> cycling74.com/download/jitter15doc.zip ), there's stated that from  
> as Jitter 1.5 there's full support for multiprocessoring system.
> I get reasonalbe performance and definitely don't get stuck at 50%  
> of my systems maximum...
>
> check it out! think that could do the trick. ( download link:  
> https://cycling74.com/downloads/jitter )
>
> greets
> david
>
> On 8/22/06, Keith McMillen  wrote:
> Hi,
>
> I'm running Jitter 1.42 and Max 4.57 on a dual core AMD & Win XP.
>
> So I have a couple of QT movies playing at 15 fps (encoded photo  
> JPEG at 15fps 320 x 240) and some processing and the two cores are  
> running at about 50% for Max and 49% System Idle.
>
> Now when I add more video processing to the exact same movies my  
> frame rate drops to 4 fps but my CPU usage remains the same Max:  
> 50% and System Idle: 49%.
>
> What limits Max/Jitter from using more of the CPU? Any way to open  
> this up to say 70%. MSP is turned off (it's a video only machine)  
> and I have mucked with scheduler settings to no avail.
>
> Thanks,
>
> Keith
>
>
> Keith McMillen
> BEAM Foundation
> http://www.beamfoundation.org/
> 510.502.5310
>
>
>
>

Oops. I didn't notice that you were running 1.2.4 Keith. You 

definitely need Jitter 1.5 for any MP benefit. However, I'd like to 

clarify that there's not exactly "full support for multiprocessing 

system", only pointwise operators as mentioned previously will use 

multiple threads (in the future perhaps more spatial operators than 

jit.convolve will exploit multiple core machines).

> I've doing something similar also on a windows machine (Intel dual  
> core though).
> Anyhoo i think u might profit from downloading Jitter 1.5, since in  
> the 'whats new' document (found on the cycling site > http:// 
> cycling74.com/download/jitter15doc.zip ), there's stated that from  
> as Jitter 1.5 there's full support for multiprocessoring system.
> I get reasonalbe performance and definitely don't get stuck at 50%  
> of my systems maximum...
>
> check it out! think that could do the trick. ( download link:  
> https://cycling74.com/downloads/jitter )

Oops. I didn't notice that you were running 1.2.4 Keith. You  
definitely need Jitter 1.5 for any MP benefit. However, I'd like to  
clarify that there's not exactly "full support for multiprocessing  
system", only pointwise operators as mentioned previously will use  
multiple threads (in the future perhaps more spatial operators than  
jit.convolve will exploit multiple core machines).

Am already running Jitter 1.52. (Typos am us - not running 1.42 or 1.24)

I can see that the processor load is equally shared between the two cores, both at about 50%. I'm not adding any more QT players just some more intensive processing of the same matrices. The fps drops (in all patches) but Jitter is not using any more CPU cycles and the rest of the 49% are sitting there idle doing me about as much good as an elected official in December. Hmmmm.

"And also try changing the Max Options > Performance Options, such as slop, poll & low priority throttles, etc; it made a suprisingly big difference to the max CPU usage on my setup."

Any recomended settings? I've already Monte Carlo'ed the page with out much luck.

Am already running Jitter 1.52. (Typos am us - not running 1.42 or 1.24) 

I can see that the processor load is equally shared between the two cores, both at about 50%. I'm not adding any more QT players just some more intensive processing of the same matrices.  The fps drops (in all patches) but Jitter is not using any more CPU cycles and the rest of the 49% are sitting there idle doing me about as much good as an elected official in December. Hmmmm.

"And also try changing the Max Options > Performance Options, such as slop, poll & low priority throttles, etc; it made a suprisingly big difference to the max CPU usage on my setup." 

Keith
Joshua Kit Clayton  wrote: 
On Aug 22, 2006, at 12:56 AM, david vandenbogaerde wrote:

On Aug 22, 2006, at 12:26 PM, Keith McMillen wrote:

> I can see that the processor load is equally shared between the two 

> cores, both at about 50%. I'm not adding any more QT players just 

> some more intensive processing of the same matrices. The fps drops 

> (in all patches) but Jitter is not using any more CPU cycles and 

> the rest of the 49% are sitting there idle doing me about as much 

> good as an elected official in December. Hmmmm.

I believe it's safe to say that this is one thread running 

alternatingly on two processors (50% o the time on one and 50% of the 

time on another). So I think it's safe to say that single threaded 

objects must be your bottle neck. You won't be able to get around 

this without re-architecting yuor patch somehow (as mentioned 

previously, running two copies of MaxMSP is probably a good approach 

to take. in general, spawning multiple processes is the typical way 

to exploit the processing power of multi-core architectures in the 

absence of a multi-threaded application which is capable of doing 

> "And also try changing the Max Options > Performance Options, such 

> as slop, poll & low priority throttles, etc; it made a suprisingly 

> big difference to the max CPU usage on my setup."

> Any recomended settings? I've already Monte Carlo'ed the page with 

Increasing the queuethrottle is usually what gives people better 

performance. The queue throttle corresponds to how many UI elements, 

qmetros, etc. are fired per low priority queue servicing. However if 

you don't have a lot of UI objects or (q)metros, then you likely 

Of course, I'd lobby again for focusing your development on GPU based 

processing rather than CPU based processing, including the UYVY - 

>RGBA conversion on the graphics card per previous threads. If you 

rearchitect your patch to use the GPU, you should be able to process 

> I can see that the processor load is equally shared between the two  
> cores, both at about 50%. I'm not adding any more QT players just  
> some more intensive processing of the same matrices.  The fps drops  
> (in all patches) but Jitter is not using any more CPU cycles and  
> the rest of the 49% are sitting there idle doing me about as much  
> good as an elected official in December. Hmmmm.

I believe it's safe to say that this is one thread running  
alternatingly on two processors (50% o the time on one and 50% of the  
time on another). So I think it's safe to say that single threaded  
objects must be your bottle neck. You won't be able to get around  
this without re-architecting yuor patch somehow (as mentioned  
previously, running two copies of MaxMSP is probably a good approach  
to take. in general, spawning multiple processes is the typical way  
to exploit the processing power of multi-core architectures in the  
absence of a multi-threaded application which is capable of doing  
similar on a thread level.)

> "And also try changing the Max Options > Performance Options, such  
> as slop, poll & low priority throttles, etc; it made a suprisingly  
> big difference to the max CPU usage on my setup."
>
> Any recomended settings? I've already Monte Carlo'ed the page with  
> out much luck.

Increasing the queuethrottle is usually what gives people better  
performance. The queue throttle corresponds to how many UI elements,  
qmetros, etc. are fired per low priority queue servicing. However if  
you don't have a lot of UI objects or (q)metros, then you likely  
won't see any benefit.

Of course, I'd lobby again for focusing your development on GPU based  
processing rather than CPU based processing, including the UYVY - 
 >RGBA conversion on the graphics card per previous threads. If you  
rearchitect your patch to use the GPU, you should be able to process  
*much* higher resolutions at >30fps.

So, offlist, I discovered that one of Keith's bottlenecks was using a 

modified version of the jit.gl.render-grid.pat example patch. There's 

a few things I'd like to share with the list regarding this patch. 

First off it's an old patch (Jitter 1.0), and there's some better 

ways to do it now. Secondly, there are some things in the patch which 

can be sped up. I've included my comments to Keith and an example 

patch using newer techniques (jit.gl.texture, jit.gl.mesh, jit.matrix 

exprfill), together with some optimizations. OpenGL rendering in 

Jitter is single threaded, so you're not going to get any benefit 

1. the first thing in the jit.gl.render-grid.pat patch is that if I 

run at a high resolution (like 256x256 vertices), I can get a 

noticeable speedup by eliminating all the unnecessary jit.pwindows in 

the patch which need to do float->char conversion, and/or downsampling.

2. I also got another 10-15% by disabling the interpolation for the 

initial jit.matrix, and if you don't need to convert the green color 

channel to alpha, you can save some CPU, by eliminating this stage 

3. A cheap RGB-> luminance conversion is to just grab the green color 

4. You can save a few more cycles by eliminating the jit.op @op * for 

z displacement, and instead rely on the ob3d scale method

5. using @unique 1 to jit.qt.movie you'll use less CPU for redundant 

frames (only an issue if your movie framerate is less than the patch 

6. using jit.gl.mesh, you may get even better performance.

So, offlist, I discovered that one of Keith's bottlenecks was using a  
modified version of the jit.gl.render-grid.pat example patch. There's  
a few things I'd like to share with the list regarding this patch.  
First off it's an old patch (Jitter 1.0), and there's some better  
ways to do it now. Secondly, there are some things in the patch which  
can be sped up. I've included my comments to Keith and an example  
patch using newer techniques (jit.gl.texture, jit.gl.mesh, jit.matrix  
exprfill), together with some optimizations. OpenGL rendering in  
Jitter is single threaded, so you're not going to get any benefit  
from Multicore CPUs there...

1. the first thing in the jit.gl.render-grid.pat patch is that if I  
run at a high resolution (like 256x256 vertices), I can get a  
noticeable speedup by eliminating all the unnecessary jit.pwindows in  
the patch which need to do float->char conversion, and/or downsampling.

2. I also got another 10-15% by disabling the interpolation for the  
initial jit.matrix, and if you don't need to convert the green color  
channel to alpha, you can save some CPU, by eliminating this stage  
entirely.

3. A cheap RGB-> luminance conversion is to just grab the green color  
channel (green is 70% of luminance data)

4. You can save a few more cycles by eliminating the jit.op @op * for  
z displacement, and instead rely on the ob3d scale method

5. using @unique 1 to jit.qt.movie you'll use less CPU for redundant  
frames (only an issue if your movie framerate is less than the patch  
framerate).

> Now when I add more video processing to the exact same movies my frame rate drops to 4 fps but my CPU usage remains the same Max: 50% and System Idle: 49%.

This sounds very much like a problem I had. The clue there was that jitter didn't support multiple processors for the operations I used, but the OS tried to balance cpu load by running the same process -alternately- on two cpus. Your cpu meter averages the cpu load and reports 50% on both cpu's where actually the cpu switches from 100% on the first and 0% on the second to 0% on the first and 100% on the second very rapidly.

These changes did speed up the patches performance and when combined with my other Jit patches (needed for the rest of the localization, reactive processing, etc...) I have doubled total frame rate from 4 fps to 8-9 fps. CPU still sits at 50%. Interstingly, the variation of the jit.gl.render-grid.pat you sent, with none of the other patches running is 50 fps (movie rate) at 17% of both cores of the CPU as claimed by XP. Very fast. It just grinds to a halt with the rest of my patch loaded.

Discussions of these observations with Adrian Freed and John Lazzaro make us suspect a cache problem. The mem needed for the renedering combined with other processes ( there are many intermediate matrices before and after the gl.render ) exceeds the cache at some point and this may be the bottleneck keeping the CPU from exceeding 50%. So running 2 Max/Jitter instances using the same cache, according to this theory, would not help. More tests needed to verify.

So this again makes me want to run the equivalent process (exemplified in the jit.gl.render-grid.pat) on the GPU. Can someone point me to the nearest shader that can get us started?

  These changes did speed up the patches performance and when combined with my other Jit patches (needed for the rest of the localization, reactive processing, etc...) I have doubled total frame rate from 4 fps to 8-9 fps. CPU still sits at 50%. Interstingly, the variation of the jit.gl.render-grid.pat you sent, with none of the other patches running is 50 fps (movie rate) at 17% of both cores of the CPU as claimed by XP. Very fast. It just grinds to a halt with the rest of my patch loaded.

  Discussions of these observations with Adrian Freed and John Lazzaro make us suspect a cache problem. The mem needed for the renedering combined with other processes ( there are many intermediate matrices before and after the gl.render ) exceeds the cache at some point and this may be the bottleneck keeping the CPU from exceeding 50%. So running 2 Max/Jitter instances using the same cache, according to this theory, would not help. More tests needed to verify.

  So this again makes me want to run the equivalent process (exemplified in the jit.gl.render-grid.pat) on the GPU. Can someone point me to the nearest shader that can get us started? 

So, offlist, I discovered that one of Keith's bottlenecks was using a 
modified version of the jit.gl.render-grid.pat example patch. There's 
a few things I'd like to share with the list regarding this patch. 
First off it's an old patch (Jitter 1.0), and there's some better 
ways to do it now. Secondly, there are some things in the patch which 
can be sped up. I've included my comments to Keith and an example 
patch using newer techniques (jit.gl.texture, jit.gl.mesh, jit.matrix 
exprfill), together with some optimizations. OpenGL rendering in 
Jitter is single threaded, so you're not going to get any benefit 
from Multicore CPUs there...

1. the first thing in the jit.gl.render-grid.pat patch is that if I 
run at a high resolution (like 256x256 vertices), I can get a 
noticeable speedup by eliminating all the unnecessary jit.pwindows in 
the patch which need to do float->char conversion, and/or downsampling.

2. I also got another 10-15% by disabling the interpolation for the 
initial jit.matrix, and if you don't need to convert the green color 
channel to alpha, you can save some CPU, by eliminating this stage 
entirely.

3. A cheap RGB-> luminance conversion is to just grab the green color 
channel (green is 70% of luminance data)

4. You can save a few more cycles by eliminating the jit.op @op * for 
z displacement, and instead rely on the ob3d scale method

5. using @unique 1 to jit.qt.movie you'll use less CPU for redundant 
frames (only an issue if your movie framerate is less than the patch 
framerate).

as it was suggested before, you could run a part of your process in runtime and the other in max.

mxj net.maxhole makes the link quite easy between them on the same computer when only messages

other solutions are possible for what concerns jitter matrix transfer if you need that.

> These changes did speed up the patches performance and when combined with my other Jit patches

> (needed for the rest of the localization, reactive processing, etc...) I have doubled total

> frame rate from 4 fps to 8-9 fps. CPU still sits at 50%. Interstingly, the variation of the

> jit.gl.render-grid.pat you sent, with none of the other patches running is 50 fps (movie rate)

> at 17% of both cores of the CPU as claimed by XP. Very fast. It just grinds to a halt with the

> Discussions of these observations with Adrian Freed and John Lazzaro make us suspect a cache

> problem. The mem needed for the renedering combined with other processes ( there are many

> intermediate matrices before and after the gl.render ) exceeds the cache at some point and this

> may be the bottleneck keeping the CPU from exceeding 50%. So running 2 Max/Jitter instances

> using the same cache, according to this theory, would not help. More tests needed to verify.

> So this again makes me want to run the equivalent process (exemplified in the

> jit.gl.render-grid.pat) on the GPU. Can someone point me to the nearest shader that can get us

> So, offlist, I discovered that one of Keith's bottlenecks was using a

> modified version of the jit.gl.render-grid.pat example patch. There's

> a few things I'd like to share with the list regarding this patch.

> First off it's an old patch (Jitter 1.0), and there's some better

> ways to do it now. Secondly, there are some things in the patch which

> can be sped up. I've included my comments to Keith and an example

> patch using newer techniques (jit.gl.texture, jit.gl.mesh, jit.matrix

> exprfill), together with some optimizations. OpenGL rendering in

> Jitter is single threaded, so you're not going to get any benefit

> 1. the first thing in the jit.gl.render-grid.pat patch is that if I

> run at a high resolution (like 256x256 vertices), I can get a

> noticeable speedup by eliminating all the unnecessary jit.pwindows in

> the patch which need to do float->char conversion, and/or downsampling.

> 2. I also got another 10-15% by disabling the interpolation for the

> initial jit.matrix, and if you don't need to convert the green color

> channel to alpha, you can save some CPU, by eliminating this stage

How to get beyond 50% CPU useage for Jitter