Georg Hajdu

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?

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?

efficiency-of-js-vs-mxj-or-better-lack-thereof

> 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

> 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,

no.  there are no speedups that js can learn from mxj, if that's what
you're implying.

> in all the tests I've seen mxj is faster than js by at least that 

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.

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

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/

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. 

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 

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

On 8 Mar 2006, at 17:24, Georg Hajdu wrote:

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 

nick rothwell -- composition, systems, performance -- 

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

   nick rothwell -- composition, systems, performance -- http:// 
www.cassiel.com


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.

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.

FWIW, as mentioned, processing *large* lists is typically most 

efficiently handled with Jitter. That's what it's optimized for.

FWIW, as mentioned, processing *large* lists is typically most  
efficiently handled with Jitter. That's what it's optimized for.

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?

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

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 

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

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 ?

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 ?

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.

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


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

"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

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.

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 !

"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 !


>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

Nice I will try doing this, looks promising. Thanks !

>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 !


Large lists of different data types, varying length and up to 2048 

Large lists of different data types, varying length and up to 2048  
elements? That's new to me.

On Mar 8, 2006, at 9:39 PM, Georg Hajdu wrote:

> Large lists of different data types, varying length and up to 2048 

Varying length and up to 2048 elements (or much more), sure. 

Different datatypes, no. Needs to be homogenous and numeric for Jitter.

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

http://www.parasitaere-kapazitaeten.net/ext/

I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I 

You will not be saved by the Holy Ghost. You will not be saved by the 

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.

On 9-Mar-2006, at 6:39, Georg Hajdu wrote:

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 

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 

Kannst gerne auch offlist fragen, wenn's Dir so lieber ist...

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:-).

by the way, Graham, if you got advices on how to "quickly" embedd python 

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

Atomatic C/C++ python bindings Never tried it, but there's

http://www.riverbankcomputing.com/Docs/sip4/sipref.html

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.

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.

By co-winky-dink, I came across another automatic Python-C++ binding

http://public.kitware.com/Cable/HTML/Index.html

By co-winky-dink, I came across another automatic Python-C++ binding
program:  cable -> http://public.kitware.com/Cable/HTML/Index.html

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