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

Mar 7, 2006 at 4:33am

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, and if yes,
can we expect a performance boost for js any time in the near future?

Georg

#24749
Mar 8, 2006 at 3:34pm

> 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

#72066
Mar 8, 2006 at 5:24pm

> 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

#72067
Mar 8, 2006 at 7:35pm

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:

http://weblogs.mozillazine.org/roadmap/

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

#72068
Mar 8, 2006 at 8:29pm

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://
http://www.cassiel.com

#72069
Mar 8, 2006 at 10:19pm

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

#72070
Mar 8, 2006 at 11:16pm

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

-Joshua

#72071
Mar 8, 2006 at 11:34pm

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

#72072
Mar 8, 2006 at 11:50pm

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

#72073
Mar 9, 2006 at 12:26am

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

#72074
Mar 9, 2006 at 12:51am

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

#72075
Mar 9, 2006 at 12:53am

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

#72076
Mar 9, 2006 at 1:03am

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

#72077
Mar 9, 2006 at 1:06am

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

#72078
Mar 9, 2006 at 5:39am

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

Georg

#72079
Mar 9, 2006 at 6:04am

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

#72080
Mar 9, 2006 at 6:43am

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

python? …

v a d e //

http://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!

#72081
Mar 9, 2006 at 2:45pm

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.

#72082
Mar 9, 2006 at 4:34pm

#72083
Mar 10, 2006 at 11:26am

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

#72084
Mar 10, 2006 at 12:01pm

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

#72085
Mar 10, 2006 at 1:04pm

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

wes

#72086

You must be logged in to reply to this topic.