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 program: cable -> http://public.kitware.com/Cable/HTML/Index.html
      wes