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/

    • 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.