Some preliminary experiments on 4+ cpu core (or 2 or more dual core cpus)

machines suggest that even though apparently OSX does some load balancing,

Max/MSP/Jitter appears not to benefit from it much if at all. Namely, when

pushing 100+% cpu load (which is in effect 1/4th of the overall machine's

computational power) Max gets bogged down and behaves as if there is no more

computational power left even though most of its load is cpu-based (rather

Composition, Music Technology, CCTAD, CHCI

http://www.music.vt.edu/people/faculty/bukvic/

Some preliminary experiments on 4+ cpu core (or 2 or more dual core cpus)
machines suggest that even though apparently OSX does some load balancing,
Max/MSP/Jitter appears not to benefit from it much if at all. Namely, when
pushing 100+% cpu load (which is in effect 1/4th of the overall machine's
computational power) Max gets bogged down and behaves as if there is no more
computational power left even though most of its load is cpu-based (rather
than gpu-based).

Ivica Ico Bukvic, D.M.A.
Composition, Music Technology, CCTAD, CHCI
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-1137
(540) 231-5034 (fax)
ico@vt.edu
http://www.music.vt.edu/people/faculty/bukvic/
http://ico.bukvic.net


smp-optimizations

DSP indeed is limited to one cpu. I don't know if the event scheduler of max is using the same cpu or is free to move. Jitter uses quicktime which does know how to adress multiple cpu's. This is how I understand it.

> DSP indeed is limited to one cpu. I don't know if the event scheduler of

> max is using the same cpu or is free to move. Jitter uses quicktime which

> does know how to adress multiple cpu's. This is how I understand it.

Although, based on my experiments, objects such as jit.xfade and other

matrix-based operations which are not necessarily linked to quicktime appear

> DSP indeed is limited to one cpu. I don't know if the event scheduler of
> max is using the same cpu or is free to move. Jitter uses quicktime which
> does know how to adress multiple cpu's. This is how I understand it.

Although, based on my experiments, objects such as jit.xfade and other
matrix-based operations which are not necessarily linked to quicktime appear
to not benefit from using smp either.

On 24 juin 07, at 15:42, Ivica Ico Bukvic wrote:

> Although, based on my experiments, objects such as jit.xfade and other

> matrix-based operations which are not necessarily linked to 

Some jitter objects take advantage of multi-threading. AFAIK, some 

quicktime codec also benefits from mutlicore. Search in the archive 

> Although, based on my experiments, objects such as jit.xfade and other
> matrix-based operations which are not necessarily linked to  
> quicktime appear
> to not benefit from using smp either.

Some jitter objects take advantage of multi-threading. AFAIK, some  
quicktime codec also benefits from mutlicore. Search in the archive  
for more details.

Well, there are some objects (those which feature obviously 

parallelizable calculations -- calculations which don't rely on other 

calculations, mostly simply pixel operators) which are explicitly 

parallelized. jit.op comes to mind, and there are some others, but 

many objects aren't suited for this. Here's a (potentially 

incomplete) list of parallelized objects:

Objects which use QuickTime will inherit whatever parallelization 

QuickTime provides, but don't have any inherent parallelized code in 

If you believe that you're seeing incorrect (or not seeing correct) 

behavior, please send us a proper bug report (the Bug Reporting 

Guidelines are below) at support@cycling74.com and we'll take a look 

---------------------------------------------------

+++++++++++++++++++++++++++++++++++++++++++++++++++

Please report any problems you experience with clear and complete

information, including steps to reproduce, software and system

information, and where possible, an isolated example patch and crash

log. Something like the following would be ideal. This makes it

easier for us to find and fix the problems you experience. Without

such clear and complete information, it is less likely we will be

Provide a descriptive summary of the issue.

In numbered format, detail the exact steps taken to produce the bug.

Describe what you expected to happen when you executed the steps above.

Please explain what actually occurred when steps above are executed.

Describe circumstances where the problem occurs or does not occur,

such as software versions and/or hardware configurations.

Provide additional information, such as references to related

problems, workarounds and relevant attachments.

Am 24.06.2007 um 15:42 schrieb Ivica Ico Bukvic:

>> DSP indeed is limited to one cpu. I don't know if the event 

>> max is using the same cpu or is free to move. Jitter uses 

>> does know how to adress multiple cpu's. This is how I understand it.

Well, there are some objects (those which feature obviously  
parallelizable calculations -- calculations which don't rely on other  
calculations, mostly simply pixel operators) which are explicitly  
parallelized. jit.op comes to mind, and there are some others, but  
many objects aren't suited for this. Here's a (potentially  
incomplete) list of parallelized objects:

jit.3m
jit.alphablend
jit.argb2grgb
jit.brcosa
jit.charmap
jit.chromakey
jit.clip
jit.colorspace
jit.convolve
jit.fluoride
jit.gencoord
jit.gl.nurbs
jit.glop
jit.grgb2argb
jit.hsl2rgb
jit.hue
jit.keyscreen
jit.lumakey
jit.map
jit.noise
jit.normalize
jit.op
jit.openexr
jit.rgb2hsl
jit.rgb2luma
jit.scalebias
jit.scanslide
jit.slide
jit.traffic
jit.xfade

Objects which use QuickTime will inherit whatever parallelization  
QuickTime provides, but don't have any inherent parallelized code in  
them.

If you believe that you're seeing incorrect (or not seeing correct)  
behavior, please send us a proper bug report (the Bug Reporting  
Guidelines are below) at support@cycling74.com and we'll take a look  
at it.

---------------------------------------------------
+++++++++++++++++++++++++++++++++++++++++++++++++++

Please report any problems you experience with clear and complete
information, including steps to reproduce, software and system
information, and where possible, an isolated example patch and crash
log. Something like the following would be ideal. This makes it
easier for us to find and fix the problems you experience. Without
such clear and complete information, it is less likely we will be
able to.

Summary:
Provide a descriptive summary of the issue.

Steps to Reproduce:
In numbered format, detail the exact steps taken to produce the bug.

Expected Results:
Describe what you expected to happen when you executed the steps above.

Actual Results:
Please explain what actually occurred when steps above are executed.

Regression:
Describe circumstances where the problem occurs or does not occur,
such as software versions and/or hardware configurations.

Notes:
Provide additional information, such as references to related
problems, workarounds and relevant attachments.

>> DSP indeed is limited to one cpu. I don't know if the event  
>> scheduler of
>> max is using the same cpu or is free to move. Jitter uses  
>> quicktime which
>> does know how to adress multiple cpu's. This is how I understand it.
>
> Although, based on my experiments, objects such as jit.xfade and other
> matrix-based operations which are not necessarily linked to  
> quicktime appear
> to not benefit from using smp either.


smp optimizations?