smp optimizations?


    Jun 23 2007 | 3:33 pm
    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).
    Any thoughts/ideas on this one?
    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

    • Jun 24 2007 | 1:34 pm
      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.
      _ johan
    • Jun 24 2007 | 1:42 pm
      > 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.
      Ico
    • Jun 24 2007 | 2:04 pm
      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 > 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.
      ej
    • Jun 24 2007 | 2:17 pm
      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.
      jb
      --------------------------------------------------- +++++++++++++++++++++++++++++++++++++++++++++++++++
      BUG REPORTING GUIDELINES
      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.
      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 >> 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.