Efficiency of js vs. mxj (or better lack thereof)


    Mar 07 2006 | 4:33 am
    In a recent test performing list operations with some code I wrote
    myself, I noticed that mxj is on average about twice as fast as js in
    low priority. I wonder whether this is a typical ratio, and if yes,
    can we expect a performance boost for js any time in the near future?
    Georg

    • Mar 08 2006 | 3:34 pm
      > In a recent test performing list operations with some code I wrote
      > myself, I noticed that mxj is on average about twice as fast as js in
      > low priority. I wonder whether this is a typical ratio,
      in all the tests I've seen mxj is faster than js by at least that amount.
      > can we expect a performance boost for js any time in the near future?
      no. there are no speedups that js can learn from mxj, if that's what
      you're implying.
      Ben
    • Mar 08 2006 | 5:24 pm
      > in all the tests I've seen mxj is faster than js by at least that
      > amount.
      I was simply wondering whether the js implementation could be tweaked
      in order to achieve a performance boost. Otherwise, I'm probably
      going to rewrite all my js objects for mxj.
      Georg
    • Mar 08 2006 | 7:35 pm
      On Mar 8, 2006, at 9:24 AM, Georg Hajdu wrote:
      > I was simply wondering whether the js implementation could be
      > tweaked in order to achieve a performance boost. Otherwise, I'm
      > probably going to rewrite all my js objects for mxj.
      Essentially we use the Mozilla spidermonkey JS implementation, which
      is arguably not the fastest one available, but stable, robust, and
      straightforward to integrate. We have no plans to perform specific
      optimization to make spidermonkey faster, if that is what you're
      asking. Nor does mozilla.org, to the best of my knowledge. Instead
      they allegedly are working on a new implementation which exploits a
      generic VM model more like the Java VM, .NET, MONO project, or PERL
      6's Parrot. This would have the potential of JIT compilation benefits
      as shown in these projects as well as open the door to other language
      implementations for the VM. I have no idea when this new
      implementation will be in place, and yet still, mature enough for us
      to consider. Those of you that have any interest in this sort of
      thing might want to check out Brendan Eich's blog:
      Here's an article with some good comments to read w/r/t the Mozilla
      2.0 VM goals (I'm not sure if any of this has been decided yet):
      http://weblogs.mozillazine.org/roadmap/archives/2004/06/
      mozilla_20_virt.html
      In the meantime, one strategy however for performing block
      calculations of on many values at once in either js or mxj is to use
      the Jitter objects, potentially jit.expr. This is something like
      10-40x faster than performing the calculations in JS on arrays of
      values, and can be 1.5-4x as fast as doing them in Java. Of course
      the larger the dataset, the larger the factor of improvement, as
      there is some overhead from either system to call into the Jitter
      objects. If your processing conforms to this block calculation model,
      I would suggest reading thoroughly the Jitter tutorials on use within
      js or mxj. Keep in mind that Jitter objects just operate on datasets.
      They need not be video or 3d geometry.
      Otherwise, yes, you should port your code to mxj or native C code for
      improved performance (keep in mind mxj has performance penalties on
      inlet and outlet calls as they need to make an expensive VM context
      switch, and so if they do not perform much processing, might be less
      efficient than a JS implementation). In general, JS is much better
      suited for quick prototyping, and operations which aren't going to be
      the bottlenecks in your application. Note that it typically only
      makes sense to optimize the bottlenecks in any application, as
      optimizing non-bottlenecks often results in negligible performance
      gains.
      Hope this helps.
      -Joshua
    • Mar 08 2006 | 8:29 pm
      On 8 Mar 2006, at 17:24, Georg Hajdu wrote:
      > I was simply wondering whether the js implementation could be
      > tweaked in order to achieve a performance boost. Otherwise, I'm
      > probably going to rewrite all my js objects for mxj.
      An approach which I'm finding very successful is to use Java for all
      the algorithmic stuff and JSUI for user interface design. Since JSUI
      does have some performance issues, I implement strobe threads inside
      Java to refresh the JavaScript GUI at a sensible rate (and/or however
      fast I can get away with).
      -- N.
      nick rothwell -- composition, systems, performance -- http://
      www.cassiel.com
    • Mar 08 2006 | 10:19 pm
      Thank you, Joshua, for your detailed answer. Of course, I'm mainly
      concerned about bottlenecks. Clearly, for the manipulations of large
      lists mxj is the way to go. I was first seduced by the simplicity of
      JS, but I'm slowly getting the hang of Java programming.
      Georg
    • Mar 08 2006 | 11:16 pm
      FWIW, as mentioned, processing *large* lists is typically most
      efficiently handled with Jitter. That's what it's optimized for.
      -Joshua
    • Mar 08 2006 | 11:34 pm
      Quote: jkc wrote on Wed, 08 March 2006 12:35
      ----------------------------------------------------
      > is arguably not the fastest one available, but stable, robust, and
      > straightforward to integrate. We have no plans to perform specific
      > optimization to make spidermonkey faster, if that is what you're
      > asking. ----------------------------------------------------
      since we're talking about the future, i picked something up about full python support in the future, is there any chance of that happening?
      seems not with C, JS and MXJ, but...
      cheers
      isjtar
    • Mar 08 2006 | 11:50 pm
      We have no plans here for Python support. However, we can most likely
      offer advice to third parties looking to implement this (check out
      the work that Thomas Grill and Bill Orcutt have already done w/r/t
      python in the meantime). In Max 5, it should be even easier for third
      parties to make language bindings. Before then it's a bit brutal to
      implement all of the patcher/box/scripting features, and some of the
      implementation must remain private (since it's changing and we won't
      support the current model's implementation in Max 5...don't worry
      from patcher/JS/Java will remain the same, I'm just talking for
      people working on language bindings).
      -Joshua
    • Mar 09 2006 | 12:26 am
      Little question regarding this. I am working on a graphical object to display a waveform.
      I currently load a sound buffer into MXJ and then I scan the array to find the max value in windows of 500 samples. I basically have a for loop within another for loop and find the max value at each 500 sample. Would it be better for me to do this using jitter ?
      Thanks,
      Nat
    • Mar 09 2006 | 12:51 am
      Nat,
      You may consider using both the maximum and minimum values within this
      block of 500 samples, and draw a vertical line segment between these two
      values. This would mimic the waveform object, if you're interested in that.
      -jim
    • Mar 09 2006 | 12:53 am
      You could probably do faster with jit.buffer~ and jit.3m. I think
      that each of these objects are instantiable from JS and Java, however
      let us know if you come across any problems.
      You can also use jit.buffer~ to perform the waveform calculation for
      you if you like.
      -Joshua
    • Mar 09 2006 | 1:03 am
      "You may consider using both the maximum and minimum values within this
      block of 500 samples, and draw a vertical line segment between these two
      values."
      This is exactely what I'm doing. I did it in JavaScript first and it was painfully slow. Now the loading of the buffer and scanning of the array is done in MXJ while the drawing is done in JSUI. Much faster but still slow when dealing with large buffers.
      I also implemented a marker system which consists of a simple vertical line (this is in the JSUI section) for some reason each time I add a marker my ram usage increments by about 1.5 megs and it becomes very slow if I add about 40 markers... Really strange. The marker and waveform are drawn in separate sketches.
      EDIT :
      Just noticed you mentioned minimum value. You're right, I'm currently only sampling the max value and drawing the line from that value to it's opposite in the negative part. Not as accurate but I beleive it's faster to sample only 1 value. I might consider this though if it's faster using the technique Joshua suggested. Thanks for the tip !
    • Mar 09 2006 | 1:06 am
      >You could probably do faster with jit.buffer~ and jit.3m. I think
      >that each of these objects are instantiable from JS and Java, however
      >let us know if you come across any problems.
      >You can also use jit.buffer~ to perform the waveform calculation for
      >you if you like.
      Nice I will try doing this, looks promising. Thanks !
    • Mar 09 2006 | 5:39 am
      Large lists of different data types, varying length and up to 2048
      elements? That's new to me.
      Georg
    • Mar 09 2006 | 6:04 am
      On Mar 8, 2006, at 9:39 PM, Georg Hajdu wrote:
      > Large lists of different data types, varying length and up to 2048
      > elements? That's new to me.
      Varying length and up to 2048 elements (or much more), sure.
      Different datatypes, no. Needs to be homogenous and numeric for Jitter.
      -Joshua
    • Mar 09 2006 | 6:43 am
      python? ...
      v a d e //
      www.vade.info
      abstrakt.vade.info
      I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I
      LIVE! I LIVE! I LIVE! I LIVE!
      You will not be saved by the Holy Ghost. You will not be saved by the
      God Plutonium.
      In fact, YOU WILL NOT BE SAVED!
    • Mar 09 2006 | 2:45 pm
      On 9-Mar-2006, at 6:39, Georg Hajdu wrote:
      > Large lists of different data types, varying length and up to 2048
      > elements? That's new to me.
      No, Jitter is multi-dimensional Arrays (I'm going back to Wirth's
      taxonomy of data structures: arrays, structures, sets).
      For managing varying data types, varying length, etc., you might want
      to look into iCE.
      What with installing XCode and Subversion and everything else I'm
      afraid I haven't transferred my .sigs to Mail 2.0 yet, but there are
      plenty of copies of old mails with the URI scattered around the forum
      (and probably on your hard disk:-).
      Kannst gerne auch offlist fragen, wenn's Dir so lieber ist...
      -- P.
    • Mar 09 2006 | 4:34 pm
    • Mar 10 2006 | 11:26 am
      by the way, Graham, if you got advices on how to "quickly" embedd python
      into C code, i take it ! ;-D
      that's my f****** problem these days...
      cheers
      f.e
    • Mar 10 2006 | 12:01 pm
      Atomatic C/C++ python bindings Never tried it, but there's
      http://www.riverbankcomputing.com/Docs/sip4/sipref.html . There may
      be others out there. I've heard they can be finicky, but if you know
      what they're finicky about, it's not really an issue.
      wes
    • Mar 10 2006 | 1:04 pm
      By co-winky-dink, I came across another automatic Python-C++ binding
      wes