[chuck-users] I have serious doubts concerning the idea of porting the VM to JS

[Bastian Schumacher]

Am 11.02.2009 um 21:23 schrieb Stephen Sinclair:

> 2) Port the VM to JavaScript.  Several JS engines are now available
> that provide exceptionally amazing JIT-based optimization.  The
> browser wars are providing a great incentive for research here, and
> there's no reason we can't piggy-back on it.  Using V8 or TraceMonkey,
> you'd get pretty good speed, while at the same time opening up the
> possibilities of adding dynamic features to the language.  You get
> things like closures and memory management for free.  Big downside:
> possibly lose real-time safety.


I currently write a project in Java. The reason (and the only reason)  
to rewrite the audio engine using ChucK is the poor timing of the  
JVM. JIT based optimization is amazing but it is exactly opposed to  
our needs when it comes to real time performance. True realtime  
performance can only be measured by the worst case, not by the  
average calculation time.
The general purpose developer would always accept a slightly inferior  
worst case scenario as long as the average performance is improved.  
This increases overhead for realtime application and - if at all - it 
´s only suitable for soft realtime applications. ChucK is likely to  
loose its biggest advantage if a JS engine would be used.


Am 11.02.2009 um 21:23 schrieb Stephen Sinclair:

> 1) Port the VM to LLVM.  Since ChucK is statically typed like C, it
> would basically allow us to use ChucK to write code that executes as
> fast as C.  This would truly allow writing UGens straight in ChucK
> code for example, with little to no drawback as compared to
> implementing UGens in C++.  Drawback is that adding new language
> features would require implementing them basically from scratch.


This idea sounds much better to me.


just my 2 cents

Basti