Alexandre

Since 5 years that I made these little efficiency tests (attached here), there have been many discussion on the forum about javascript vs java vs C, and the feeling that often comes out - false, i think - is illustrated by this Emmanuel Jourdan sentence :

"JavaScript is slower than Java indeed, and Java is slower than C. That's in term of CPU/memory usage. In term of development time, it's about the inverse..." ( 

https://cycling74.com/forums/max-vs-java-vs-javascript-speed

Javascript execution is not only 3, 10 or 20 times slower than java, it IS between 200 times and 400 times slower than Java, in my test: In 4 millisec., my little test calculation loop is computed only 200 times in js, while 40000 times in java, on my MBP. (As probably every 'interpreted' code, max patchers execution is also around the same speed, 200 times slower than Java.) Now Java is about 1,5 slower than the C test (non-block-calculation), which, in most situations, is almost nothing. Ok for java, there is this JVM bridge little bottleneck every time that you cross an inlet/outlet, which is around 1 microsecond. Ok that's not always negligible, but well, when you make an mxj or javascript object, ...you are making your loops inside it, so you're not supposed to [uzi] very fast over it... By crossing this JVM bridge the less often possible, for example by joining numbers into list before sending thru an inlet/outlet (which mean crossing this bridge only once) i'm then really peaceful with this bridge, since 5 years, and there's no point for me to go to C.

To me, if you use it to make some max objects the same way you would using Javascript, Java is as easy to learn. (It will only be more complex to learn if you want to go further thru "inheritance" concepts and stuff... to things you can't do with javascript.)

Now, using the great Eclipse developing environment for Java - far better than the Java editor inside max - the development time should be - at least - AS FAST AS Javascript. The assisted editing make it even more convenient than javascript. Just the syntax is a little bit different from Javascript but it's not few more semicolons that are gonna slow you down.

About C, beside its slower development time, a real pain is that, from what i understood, you have to restart max every time you modify your object. ( 

https://cycling74.com/forums/how-to-load-rebuilt-external-without-reopening-max

 ) Not the case in java and javascript where you can refresh the max object.

There's a great 'Step by Step Instructions tutorial' from Adam Murray, to use Eclipse with max: 

http://compusition.com/web/articles/maxmsp-eclipse

...in just a half an hour process, you're into java... So why Javascript ?

I understand that the Javascript field is non-timing-sensitive stuff*, like UI related code, but in the beginning era of multi-touch - cf. 

http://www.youtube.com/watch?v=tfvEV1zcAjQ

 - then even UI related routines are going to be called more and more often, then even for that, Javascript could bring signifiant slow down, compared to java, in the future.

5 years ago, I remember a discussion with jkc saying he liked javascript, but 5 year after i'm still asking myself why.

I don't get why so much maxers are using Javascript and C, while fewer are using Java. ( 2 times more messages on the Javascript forum than on the Java forum )

P.S : But there is again worst than javascript: look at the [coll] object efficiency in the 'test-on-arrays'...

* in the WritingMaxExternalsInJava.pdf doc : "For timing sensitive events the js and jsui objects should not be used"

Since 5 years that I made these little efficiency tests (attached here), there have been many discussion on the forum about javascript vs java vs C, and the feeling that often comes out - false, i think - is illustrated by this Emmanuel Jourdan sentence : 

"JavaScript is slower than Java indeed, and Java is slower than C. That's in term of CPU/memory usage. In term of development time, it's about the inverse..." ( https://cycling74.com/forums/max-vs-java-vs-javascript-speed )

Javascript execution is not only 3, 10 or 20 times slower than java, it IS between 200 times and 400 times slower than Java, in my test: In 4 millisec., my little test calculation loop is computed only 200 times in js, while 40000 times in java, on my MBP.  (As probably every 'interpreted' code, max patchers execution is also around the same speed, 200 times slower than Java.) Now Java is about 1,5 slower than the C test (non-block-calculation), which, in most situations, is almost nothing. Ok for java, there is this JVM bridge little bottleneck every time that you cross an inlet/outlet, which is around 1 microsecond. Ok that's not always negligible, but well, when you make an mxj or javascript object, ...you are making your loops inside it, so you're not supposed to [uzi] very fast over it...  By crossing this JVM bridge the less often possible, for example by joining numbers into list before sending thru an inlet/outlet (which mean crossing this bridge only once) i'm then really peaceful with this bridge, since 5 years, and there's no point for me to go to C.

To me, if you use it to make some max objects the same way you would using Javascript, Java is as easy to learn. (It will only be more complex to learn if you want to go further thru "inheritance" concepts and stuff... to things you can't do with javascript.)
Now, using the great Eclipse developing environment for Java - far better than the Java editor inside max -  the development time should be - at least - AS FAST AS Javascript. The assisted editing make it even more convenient than javascript. Just the syntax is a little bit different from Javascript but it's not few more semicolons that are gonna slow you down.
About C, beside its slower development time, a real pain is that, from what i understood, you have to restart max every time you modify your object. ( https://cycling74.com/forums/how-to-load-rebuilt-external-without-reopening-max ) Not the case in java and javascript where you can refresh the max object.

There's a great 'Step by Step Instructions tutorial'  from Adam Murray, to use Eclipse with max: http://compusition.com/web/articles/maxmsp-eclipse 

I understand that the Javascript field is non-timing-sensitive stuff*, like UI related code, but in the beginning era of multi-touch - cf. http://www.youtube.com/watch?v=tfvEV1zcAjQ - then even UI related routines are going to be called more and more often, then even for that, Javascript could bring signifiant slow down, compared to java, in the future.

I don't get why so much maxers are using Javascript and C, while fewer are using Java. ( 2 times more messages on the Javascript forum than on the Java forum )
Perhaps it's just a lack of publicity ?
i'm making it... :-)

* in the WritingMaxExternalsInJava.pdf doc : "For timing sensitive events the js and jsui objects should not be used"


java-200-times-faster-almost-as-easy-to-use-so-why-javascript

"I don't get why so much maxers are using Javascript and C"

C is still faster. '1.5 times' is not an absolute measure for everything... and it can make a big difference very fast in the development of larger apps.

as for javascript, i'm not an expert and i do shy away from it(in Max) because i like C better, but it's the same argument as trying to say that you are happy to use Java even though you know C is faster. there's different situations suited for different things. there are situations where javascript does not take up much CPU at all. in those situations, the ease of quick scripting is applicable as an adequate substitute for lower-level programming.

also, you develop C externals outside of Max, true, therefore you have to restart, but to me it's a negligible amount of time, when people talk of 'slower development time' for C, that's completely subjective: usually more true for those who are just plain slow at using their IDE and at programming in C.

you make a good argument about javascript and java but your PPC compiling of C externals in your test while most are using intel these days and your arguments against C(while C is the cornerstone of how everything in Max was originally created), takes away from your argument by distracting it from the java/javascript relation alone and also may lead one to wonder why you've avoided the subject of C++ altogether.

It is good to hear your passion for Java, though!

I guess it really depends what you are trying to achieve.

I have and do use all three. I don't think there is a good argument for only using one.

If you (in many cases meaning me) are really serious about efficiency then C is probably the best way to go. 1.5x might be significant if you are writing audio code that is already expensive.

Java has cross-platorm on it's side (that's the big plus for me).The garbage collection is a lot easier, but I'm not usually worried about cross-platform - I know the C API very well, and I can deal with garbage collection, so normally the speed wins out - when compatibility is a concern then java is normally my choice.

Javascript is slow, but sometimes it's just the easiest. I use js a lot when I have an esoteric thing that I can't quite do in max, but the js API allows and I'm not going to want to reuse it a lot and speed is not a concern. Learning time for a language is not the only speed concern. I can write a quick routine in js in under 2 minutes and have it running. I doubt I could be as fast in java or C, even working from a template. THat is what development time means - not how long it takes for you to learn how to do it.

The last thing which you fail to consider is the API available in each. One of the quirks of developing for max is that the APIs are all different. That means that sometimes it's really straightforward to do something in one, and not in another. Let's say I want to read a textfile without character limitations in. I did it in js in less than 20 lines. I don't think I've ever written an external in java or C that was anywhere near that compact.

Great that you feel Java suits you, but each to his own. I can't help but think that when suitable, javascript is normally fastest to code, and often that is what counts.

Noob4Life, you are right about C efficiency can be better than '1.5 times' specially for block calculation (audio externals, jitter). Sorry I don't have the intel version compiled for the C test because it was made for me by a guy at ircam five years ago. I doubt the '1.5 times' would change a lot anyway.

> AlexHarker : "I can write a quick routine in js in under 2 minutes

> and have it running. I doubt I could be as fast in java, even working from a template.

from a template, that's 3 minutes for Java...

> One of the quirks of developing for max is that the APIs are all different.

Considering the too limited time that C74 team have to develop the full max API for each language, i feel that pattr and UI support for Java, instead of Javascript, might have been the best choice, for a real-time-sound-and-image software where efficiency and timing is an eternal question.

> AlexHarker :  "I can write a quick routine in js in under 2 minutes
> and have it running. I doubt I could be as fast in java, even working from a template.

>  One of the quirks of developing for max is that the APIs are all different.

Considering the too limited time that C74 team have to develop the full max API for each language, i feel that pattr and UI support for Java, instead of Javascript, might have been the best choice, for a real-time-sound-and-image software where efficiency and timing is an eternal question.


By the way. I'm not sure I believe your figures totally.

Try the below. this would seem to indicate that js slightly less than twice as slow on my computer (around 2000 milliseconds plays 3300 ish). Bang the little button...

Can you confirm your results and comment. I haven't had time to check your patch in detail but this is a simple tried and tested way of measuring speeds. I'm on intel so I didn't do the c compile...

Assuming my figures are right (which they may not be) that would somewhat change everything no?

My bad - I see now that you loop fois * 10 in the java code and fois / 10 in the js. Confusing but fair enough - that would account for the factor of 100.....

++ to mxj supporting pattr integration! Hoping it is coming soon.

++ to mxj supporting pattr integration!  Hoping it is coming soon.


any use of javascript and java inside maxmsp should be illegal.

Yes AlexHarker, It was necessary to put this /10 for js and *10 for java and c, in order to avoid: 1- minutes to wait for the js to compute, 2- eventual bad precision over java an C if the test is too short. Then the compute time is corrected by multipling by this factor. (third [chrono] inlet in my patch). Sorry if my test then looks a bit complex.

>> ++ to mxj supporting pattr integration! Hoping it is coming soon.

Do you really think that could come soon? This would be nice. But looking at theses old topics ( 

https://cycling74.com/forums/pattr-support-in-max-5

https://cycling74.com/forums/notifyclients-in-java

>> any use of javascript and java inside maxmsp should be illegal.

What should be illegal is the use of patch cords for sequential and algorithmic stuff. Looking at other people algorithmic patches just give me headaches. What i made in Java would have cost 10 time more developing time using patch cords. Keep max for its best: Real time events, audio, UI.

>>  ++ to mxj supporting pattr integration! Hoping it is coming soon.

Do you really think that could come soon?  This would be nice. But looking at theses old topics ( https://cycling74.com/forums/pattr-support-in-max-5 and https://cycling74.com/forums/notifyclients-in-java ), it doesn't look like coming soon.

>> any use of javascript and java inside maxmsp should be illegal.
What should be illegal is the use of patch cords for sequential and algorithmic stuff. Looking at other people algorithmic patches just give me headaches. What i made in Java would have cost 10 time more developing time using patch cords. Keep max for its best: Real time events, audio, UI.


Yes - I guessed as much once I'd figured that out.

I get about 160 times faster here on a dual 3.0GHz MBP.

FWIW - the javascript calculations as far as I know are double precision - the java ones are not. I wouldn't want to speculate too much on what difference it would make, but I think you'd see it in the figures.

Obviously, single precision in javascript is not an option, but it would be better to compare like with like as far as possible...

I can't help but feel however, that you are looking at large data, large loops within loops situations that may not be typical uses of javascript. I'm not going to disagree that js is bad for this, but in small applications I think you might find that worrying about cpu usage is a waste of energy. After all - if you have a process that takes 1% of your processor (for example) in a scenario where you are running at around 67% - then when you speed that up by 200 times you simply won't see it clearly in the results - so it's not good economy. If it takes up 40% of your processor however....

"Any use of javascript and java inside maxmsp should be illegal. "

I've broken the law. rehabilitate me. someone! I've been trying to get started with C/Max for 5 years now. never got off the ground. Why? The thing I've had problems with in every language isn't the language part but the way it's set up on in the OS. There are never any details about it in any tutorial. There's always a line "find foo.baz.clib on your drive" and it's never there. I've spent four years programming mxj externals and I have no frick'n clue what ANT is, how to write scripts for it, or where "java" is on my drive. I open eclipse, include max.jar and I'm done.

Maybe that makes me not a "real" programmer. I couldn't care less.

I'll try again soon when I get around to installing snow leopard but setting up max and C has taken weeks of my life and I've never gotten it right.

That comes off ranty.. but it's more a rant of desperation :-)

I've broken the law.  rehabilitate me.  someone! I've been trying to get started with C/Max for 5 years now.  never got off the ground.    Why?  The thing I've had problems with in every language isn't the language part but the way it's set up on in the OS.  There are never any details about it in any tutorial.  There's always a line "find foo.baz.clib on your drive" and it's never there.  I've spent four years programming mxj externals and I have no frick'n clue what ANT is, how to write scripts for it, or where "java" is on my drive. I open eclipse, include max.jar and I'm done.

Maybe that makes me not a "real" programmer. I couldn't care less.    

I'll try again soon when I get around to installing snow leopard but  setting up max and C has taken weeks of my life and I've never gotten it right.

That comes off ranty..  but it's more a rant of desperation :-)


I have used JS to develop two or three projects. As most of them were non -realtime I didn't care about efficiency. I chose JS essentially because I wanted to use the drawing capabilities of the JSUI object and because as a non-programmer (I mean no experience in any formal language outside Max, SuperCollider and GW-Basic). I also wanted the shortest possible learning curve.

I had one project to create rhythmic patterns using JS. Reading the resulting data in real-time with JS produced tons of clicks while reading them from colls worked correcly (althought transition between Max4 and Max5 showed some reductions in performance for very fast MIDI rhythms).

I have been thinking about learning C several times but I always postpone it.

> the javascript calculations as far as I know are double precision

I even didn't know. in attachment is the version with double in java, which is 2 time slower, in fact. (good to know)

I have a question: Is there anyone having a example patch that cannot be done using only floats precision ?

(I've never used double, and whenever i use the Java.Math methods i immediately convert in float.)

I have a question: Is there anyone having a example patch that cannot be done using only floats precision ?
(I've never used double, and whenever i use the Java.Math methods i immediately convert in float.)


> but in small applications I think you might find that worrying about cpu usage is a waste of energy.

The problem with small applications, is that they often get bigger, or that one day you need to load a bunch of them for a live or something, and then nothing is working as before and you don't know why.

If we were talking about a factor of 1,5 or 2, then ok, worrying about cpu usage for that may be a waste of time for a small application. But we are talking about a factor which is between 100 and 400 (yes, 400, see my 'Efficiency-test-on-arrays.pat': the loop is computed only 1000 times in js, while 400000 times in java, on my MBP.)

Compared with java, to me, javascript is mostly a waste of energy for the computer.

...Ecologists would even make javascript illegal, what about your computer carbon footprint?

The problem with small applications, is that they often get bigger, or that one day you need to load a bunch of them for a live or something, and then nothing is working as before and you don't know why. 

If we were talking about a factor of 1,5 or 2, then ok, worrying about cpu usage for that may be a waste of time for a small application. But we are talking about a factor which is between 100 and 400 (yes, 400, see my 'Efficiency-test-on-arrays.pat': the loop is computed only 1000 times in js, while 400000 times in java, on my MBP.)
Compared with java, to me, javascript is mostly a waste of energy for the computer.

...Ecologists would even make javascript illegal, what about your computer carbon footprint?
:-D


If MaxforLive already included LiveAPI integration for Java, I'd be on the bandwagon...for now I'll code it in js and convert it when it needs done.

(actually, I guess it makes little difference since the LiveAPI is low-priority anyway)...

Still...the link to the tutorial above is helpfull...I've already installed Eclipse and started reading about Java. There are several things I wrote in js before I had to convert them into pureMax because js was too slow. I'd much rather have them in a script language....editing algorithmic stuff in Max is like trying to popular music trends....

Still...the link to the tutorial above is helpfull...I've already installed Eclipse and started reading about Java.  There are several things I wrote in js before I had to convert them into pureMax because js was too slow.  I'd much rather have them in a script language....editing algorithmic stuff in Max is like trying to popular music trends....


Double precision is a real necessity in certain scenarios - for instance:

phasor accumulation (for audio rate buffer playback for example)

calculating certain filter coefficients accurately

My personal experience of double precision critical situations is more in the domain of audio rate programming admittedly, but that is just me.

You seem to be suggesting that doubles are unnecessary. I'm trying to suggest that everyone's needs are different, and if java is twice as slow with doubles (that is inline with what I expected) - then on my computer you are looking at closer to 75 - 80 times slower for js doing the same thing - which is a substantially different figure to 200. Sometimes the speed gains offered by C *really* matter to me, whereas to you it isn't worth it.

As for arrays - sure - I didn't say it was fast, or good for that. However, in the event that you do very little in a function call and you make the function call lets say every 10ms (which is really quite often compared to a message-based musical timing) - the CPU you might be talking about is really not worth worrying about.

Believe me II have spent many hours optimising cpu and memory usage - to the point of ridiculous obsession. I understand the drive, but rule 1 of optimisation is don't optimise. It has many disadvantages. Rule 2 is optimise what matters first. Let's take Chris Muir's simple FM patch from a recent thread. Turns out that mtof~ accounts for over 50% of the cpu that that patch consumes. I can spend all the time I want optimising other parts, but some of them are so negligible that I could put in hours and hours and never see any real gain. I replaced mtof~ with a more efficient alternative and the patch ran almost twice as fast (55% with 32 voices down to 28%)...

Often I am using js for one off calculations / loading processes / things that happen maybe less than once a minute. Unless those operations are noticeable intensive then optimisation is not a concern.

phasor accumulation (for audio rate buffer playback for example)
calculating certain filter coefficients accurately

My personal experience of double precision critical situations is more in the domain of audio rate programming admittedly, but that is just me.
You seem to be suggesting that doubles are unnecessary. I'm trying to suggest that everyone's needs are different, and if java is twice as slow with doubles (that is inline with what I expected) - then on my computer you are looking at closer to 75 - 80 times slower for js doing the same thing - which is a substantially different figure to 200. Sometimes the speed gains offered by C *really* matter to me, whereas to you it isn't worth it.

Often I am using js for one off calculations / loading processes / things that happen maybe less than once a minute. Unless those operations are noticeable intensive then optimisation is not a concern.


Alex wrote, "Often I am using js for one off calculations / loading processes / things that happen maybe less than once a minute. Unless those operations are noticeable intensive then optimisation is not a concern."

ya, this is what i was trying to say... for such contexts, a quick scripting language(like JS/Python/etc.) seems better than any small efficiency gains you get from a lower-level language.

Oh please, the days of low-level languages for general purpose programming is over (should be anyway).

Using C as an application language was never a good idea and still isn't. It was designed for system programming, and that is were low-level concepts such as direct access to memory should stay. The programming platforms of the future are probably going to be virtual machines supporting dynamic linking, JIT-compilation (which already beat AOT-compilers in speed) and garbage collection on the fly.

One reason to use JavaScript over Java is that it is a functional and more expressive language. Another is that is has direct access to the Max scheduler and object system, which Java has not. If speed is an issue, you can switch to Rhino and compile it to JVM bytecode, which will execute at java speed (this would of course restrict you to the Java API).

Hans Hoglund wrote: "Using C as an application language was never a good idea and still isn't."

I think everytime people bring C into the debate between Java and Javascript, it's going to distract from credibility on other points(JMax is dead, btw).

I agree with most of what you say, but this holds no water whatsoever considering we are all here because of an application called "Max" which was(and to a great extent still is) written in C.

Hans Hoglund wrote: "Using C as an application language was never a good idea and still isn't."
I think everytime people bring C into the debate between Java and Javascript, it's going to distract from credibility on other points(JMax is dead, btw).
I agree with most of what you say, but this holds no water whatsoever considering we are all here because of an application called "Max" which was(and to a great extent still is) written in C.


@Noob4Life I have no problem using and relying on stable software. What concerns me is that the performance arguments is used to hold back the emancipation of new and better languages. I think it should be the other way around, we should look out for more expressive ways to program and then consider implementation.

Of course Max was designed to connect C programs, that was the the accepted way to do real-time back then. Now we have other options, there are hundreds of languages with safe memory, lambdas and dynamic dispatch that are fast enough for real-time, many of which can be integrated in Max.

"I think it should be the other way around, we should look out for more expressive ways to program and then consider implementation."

well put! after all, all 'languages' serve the primary purpose of communicating and disseminating any form of information(efficiency concerns are not always paramount to communication).

if we talk of the future, i believe all apps and data will be web-based eventually, and personal comps will only be a terminal to that network, this will actually be more affordable and will provide better access to information for even 3rd world countries... sounds dangerous to comprehend at first, but since i don't think google/verizon/microsoft will ever succeed in completely limiting/commodifying our access and presence on the web, it's very possible... therefore, i agree with all your statements of what options we have and will have.

well put! after all, all 'languages' serve the primary purpose of communicating and disseminating any form of information(efficiency concerns are not always paramount to communication).
if we talk of the future, i believe all apps and data will be web-based eventually, and personal comps will only be a terminal to that network, this will actually be more affordable and will provide better access to information for even 3rd world countries... sounds dangerous to comprehend at first, but since i don't think google/verizon/microsoft will ever succeed in completely limiting/commodifying our access and presence on the web, it's very possible... therefore, i agree with all your statements of what options we have and will have.


I have never really understood why people want to do time critical

operations with Java. As a software developer designing a real-time

system, the last thing I want to build into it are unknowns like

garbage collection and byte interpreted instructions. That just

adds unknown inefficiencies that keeps you from squeezing all the

Max is an open architecture that allows you to insert your own

objects in that audio and data signal path. It is supposed to

be as efficient as possible. Implementing your algorithm in C

is probably the best compromise between readability and effecienncy.

But for doing UI stuff I think javascript is decent. Although I

think python is a much better language. I hope that one day, Cycling74

will add native support for it. I would love to have access to SciPy

I have never really understood why people want to do time critical
operations with Java. As a software developer designing a real-time
system, the last thing I want to build into it are unknowns like
garbage collection and byte interpreted instructions. That just
adds unknown inefficiencies that keeps you from squeezing all the
power you can out of your system.

Max is an open architecture that allows you to insert your own
objects in that audio and data signal path. It is supposed to
be as efficient as possible. Implementing your algorithm in C
is probably the best compromise between readability and effecienncy.

But for doing UI stuff I think javascript is decent. Although I
think python is a much better language. I hope that one day, Cycling74
will add native support for it. I would love to have access to SciPy
in Max!


"python is a much better language. I hope that one day, Cycling74

"python is a much better language. I hope that one day, Cycling74
will add native support"
+1 4 Python!


@Anthony Your arguments are just not valid. The JVM of 1990s were slow, modern implementations are not. GC and JIT are not "dumb overheads" but higly intricate compilation techniques that may actually yield 

 than a C compiler. That JVM's are slow is just a plain old myth.

What Java has is a slow startup time (about 500 ms on my machine, and this happens 

 when you load your first Java class). This is not because of JIT, but because Java links everything dynamically. The benefits of this are so huge that I have no problems with a split-second startup delay.

Furthermore I would argue that in a real-time application stability is more important than raw performance. In Java code you will never have a memory error except if you mess up concurrency. Use Clojure and you will not even have that.

@Anthony Your arguments are just not valid. The JVM of 1990s were slow, modern implementations are not. GC and JIT are not "dumb overheads" but higly intricate compilation techniques that may actually yield better performance than a C compiler. That JVM's are slow is just a plain old myth.

What Java has is a slow startup time (about 500 ms on my machine, and this happens once when you load your first Java class). This is not because of JIT, but because Java links everything dynamically. The benefits of this are so huge that I have no problems with a split-second startup delay.

Furthermore I would argue that in a real-time application stability is more important than raw performance. In Java code you will never have a memory error except if you mess up concurrency. Use Clojure and you will not even have that.


Also, why should we need to compromise readability to have efficiency? Why not use a language that has both? (Not that Java does).

>> But for doing UI stuff I think javascript is decent.

Try ej.fonction.js from the ejies, put lot's of segments and manipulate the visualizations, then javascript is not decent anymore...

Comparing a javascript code with the same thing done in java, to me, in general, that's nearly the same in term of readability. The situations were javascript really looks more "expressive", are not coming so often to me, looking at codes.

(plus, the really nice way that Eclipse manage color for instruction types and highlight other variables when you type on one, makes java even more readable, in my personal experience.)

>> Why not use a language that has both?
Good question.

Comparing a javascript code with the same thing done in java, to me, in general, that's nearly the same in term of readability. The situations were javascript really looks more "expressive", are not coming so often to me, looking at codes.
(plus, the really nice way that Eclipse manage color for instruction types and highlight other variables when you type on one, makes java even more readable, in my personal experience.)


"I would argue that in a real-time application stability is more important than raw performance. In Java code you will never have a memory error except if you mess up concurrency. Use Clojure and you will not even have that."

You obviously know your stuff, and I respect your opinion, but this argument at least is void if the programmer deals with memory allocation and access correctly. Also, as always YMMV with regards to the importance of raw performance. As we are dealing with a real time audio language here, and portable computer power is not infinite, I think it is clearly arguable that in some scenarios available processing power limits what is desirable, and therefore raw performance is highly relevant. In time critical situations 20% (as quoted in the linked article) slower may simply be unacceptable.

In reality I simply don't believe that 20% is a typical figure for what is being discussed here (max external in java vs one in C). I'd be happy to be proved wrong, but I'll be sticking to C for efficient audio processing until then.

Don't get me wrong, I'm not arguing against the use of java, I'm just think that any choice of language is based on a combination of factors, and there are clearly arguments in all directions - using the most appropriate language in the circumstances seems would be my approach, and for me that could result in using C, java or javascript.

Me, I'm not arguing against the use of C, but let's feed these interesting debates :

About C vs java, in the C74 WritingMaxExternalsInJava.pdf doc, page 43, from Topher La Fata :

Java signal processing external is typically about 1.5-2.5X slower than the equivalent

external written in C. A lot of this depends on what sort of processing your external is

doing. In most cases the more computationally expensive your external, the closer that

the Java and C versions will be in performance. This is because the biggest overhead

introduced by doing your signal processing in Java is in the context switching that occurs

when the mxj~ bridge calls from C into your Java signal processing routine. The cost of

this context switch is amortized across the amount of time you spend actually

accomplishing your task, so the more expensive your task, the less relatively expensive is

Me, I'm not arguing against the use of C, but let's feed these interesting debates :
About C vs java, in the C74 WritingMaxExternalsInJava.pdf doc, page 43, from Topher La Fata :

"A properly written
Java signal processing external is typically about 1.5-2.5X slower than the equivalent
external written in C. A lot of this depends on what sort of processing your external is
doing. In most cases the more computationally expensive your external, the closer that
the Java and C versions will be in performance. This is because the biggest overhead
introduced by doing your signal processing in Java is in the context switching that occurs
when the mxj~ bridge calls from C into your Java signal processing routine. The cost of
this context switch is amortized across the amount of time you spend actually
accomplishing your task, so the more expensive your task, the less relatively expensive is
the cost of the context switch."


"Me, I'm not arguing against the use of C," but then you go on to do just that. At least be truthful rather than hypocritical. (Also, the quote starts with the wording "typically" and "depends on what sort of processing your external is

doing", so it's not an empirical statement whatsoever.)

I think what everyone is doing here is only proving that developers are extremely high-maintenance people ;) The discussion is whittling into something uninteresting and convincing me to stay away from Java(since devs in that environ seem more desperate to talk sh!t about all others more than anyone else i've seen). What you've convinced me of, is that even though you don't think it's significant, C is still significantly faster than Java(because 1.5-2.5xfaster can make a very big cumulative difference to me).

"Me, I'm not arguing against the use of C," but then you go on to do just that. At least be truthful rather than hypocritical. (Also, the quote starts with the wording "typically" and "depends on what sort of processing your external is
doing", so it's not an empirical statement whatsoever.)

I think what everyone is doing here is only proving that developers are extremely high-maintenance people ;) The discussion is whittling into something uninteresting and convincing me to stay away from Java(since devs in that environ seem more desperate to talk sh!t about all others more than anyone else i've seen). What you've convinced me of, is that even though you don't think it's significant, C is still significantly faster than Java(because 1.5-2.5xfaster can make a very big cumulative difference to me).


With all due respect Hans, I definitely see the merit of your

argument. Java VM technology has certainly advanced in the last

But I feel a lot of these benchmarks people quote are perfect scenarios

that don't really reflect the real time performance environemnt

of an integrated system (memory latency, kernel i/o, graphics/audio

interfaces). You can argue all you want about how some JVM does an FFT faster than C, but put it in a real world environment and I think

Arguable the most complex real-time audio/graphics system out there

are console game systems like the PS3 and Xbox. Why hasn't Sony or

nVidia, chosen Java as their development language/environment of choice?

Because it is an inefficient language for that environment.

Java 200 times faster, almost as easy to use, so why Javascript ?