[Cs-dev] Virtual machines for Csound
Date | 2013-11-04 19:01 |
From | Michael Gogins |
Subject | [Cs-dev] Virtual machines for Csound |
Attachments | None None |
I would like to clarify my thoughts regarding Emscripten, Adobe's CrossBridge, LuaJIT, and other contemporary high-performance virtual machines as a platform for running Csound and other computer music software.
(Csound and its orc language are themselves, of course, a virtual machine.) In summary, Emscripten and CrossBridge take the output of a C/C++ compiler and further compile it to bytecode for a high-performance virtual machine (JavaScript V8 for Emscripten, ActionScript/Flash Play for CrossBridge). LuaJIT is, all by itself, a high-peformance virtual machine with a built in foreign function interface. At this time, Csound can embed LuaJIT via the Lua opcodes. This is installed, for example, with the Csound 6 app for Android.
These virtual machines, it should be noted, will run at anywhere from 10% to more than 100% of the speed of compiled C code. This is much faster than traditional interpreters or than older virtual machines such as CPython.
One may envision a goal in which Csound's source code is compiled to VM bytecode, and the native language of the VM is then used for score generation, front ends, add-ons, and such, and the whole will run at some appreciable fraction of Csound's native speed. In addition, such a version of Csound would run in any current Web browser, and hook into the browser's capabilities for OpenGL 3-D graphics, user interface widgets, audio input and output, video input and output, and so on.
For example, such a version of Csound could replace the current Csound 6 app for Android with an HTML 5 app running Emscripten-compiled bytecode. This would run not only on Android, but on any computer or device with a standard Web browser and JavaScript.
To compare the VMs: Emscripten LLVM front end, open source, JavaScript, browser-hosted runtime. No threads, no dynamic loading of modules. CrossBridge gcc front end, open source, ActionScript, Flash Player-hosted runtime. Threads, dynamic loading of native modules. LuaJIT
Self-hosted front end, open source, Lua, self-hosted runtime, no browser plugin (?), fastest of all. No threads in Lua, threads in native code, dynamic loading of native modules.
For me, the ideal is something like LuaJIT running in a standard Web browser, or something like JavaScript that runs as fast as LuaJIT. For example, LuaJIT will support user-defined Csound audio opcodes that run about as fast C code; I haven't done the test, but I don't think this could be done in any practical sense using user-defined JavaScript code.
One thing is clear: computing is, potentially, approaching a watershed moment in which a truly universal computing platform could appear inside the browser. At that point. one could reasonably design a computer in which the browser actually is the operating system, without any particular loss of generality or speed, and a huge gain in universality. ===========================
Michael GoginsIrreducible Productions http://michaelgogins.tumblr.com Michael dot Gogins at gmail dot com |
Date | 2013-11-04 19:12 |
From | Victor Lazzarini |
Subject | Re: [Cs-dev] Virtual machines for Csound |
In relation to opcodes, I'd also like to note that Faust-written opcodes are running in Csound at near-native speeds via a LLVM bytecode on-the-fly compiler. Victor On 4 Nov 2013, at 19:01, Michael Gogins wrote: > I would like to clarify my thoughts regarding Emscripten, Adobe's CrossBridge, LuaJIT, and other contemporary high-performance virtual machines as a platform for running Csound and other computer music software. > > (Csound and its orc language are themselves, of course, a virtual machine.) > > In summary, Emscripten and CrossBridge take the output of a C/C++ compiler and further compile it to bytecode for a high-performance virtual machine (JavaScript V8 for Emscripten, ActionScript/Flash Play for CrossBridge). LuaJIT is, all by itself, a high-peformance virtual machine with a built in foreign function interface. At this time, Csound can embed LuaJIT via the Lua opcodes. This is installed, for example, with the Csound 6 app for Android. > > These virtual machines, it should be noted, will run at anywhere from 10% to more than 100% of the speed of compiled C code. This is much faster than traditional interpreters or than older virtual machines such as CPython. > > One may envision a goal in which Csound's source code is compiled to VM bytecode, and the native language of the VM is then used for score generation, front ends, add-ons, and such, and the whole will run at some appreciable fraction of Csound's native speed. In addition, such a version of Csound would run in any current Web browser, and hook into the browser's capabilities for OpenGL 3-D graphics, user interface widgets, audio input and output, video input and output, and so on. > > For example, such a version of Csound could replace the current Csound 6 app for Android with an HTML 5 app running Emscripten-compiled bytecode. > > This would run not only on Android, but on any computer or device with a standard Web browser and JavaScript. > > To compare the VMs: > > Emscripten > > LLVM front end, open source, JavaScript, browser-hosted runtime. No threads, no dynamic loading of modules. > > CrossBridge > > gcc front end, open source, ActionScript, Flash Player-hosted runtime. Threads, dynamic loading of native modules. > > LuaJIT > > Self-hosted front end, open source, Lua, self-hosted runtime, no browser plugin (?), fastest of all. No threads in Lua, threads in native code, dynamic loading of native modules. > > For me, the ideal is something like LuaJIT running in a standard Web browser, or something like JavaScript that runs as fast as LuaJIT. > > For example, LuaJIT will support user-defined Csound audio opcodes that run about as fast C code; I haven't done the test, but I don't think this could be done in any practical sense using user-defined JavaScript code. > > One thing is clear: computing is, potentially, approaching a watershed moment in which a truly universal computing platform could appear inside the browser. At that point. one could reasonably design a computer in which the browser actually is the operating system, without any particular loss of generality or speed, and a huge gain in universality. > > =========================== > Michael Gogins > Irreducible Productions > http://michaelgogins.tumblr.com > Michael dot Gogins at gmail dot com > ------------------------------------------------------------------------------ > Android is increasing in popularity, but the open development platform that > developers love is also attractive to malware creators. Download this white > paper to learn more about secure code signing practices that can help keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk_______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
Date | 2013-11-04 19:18 |
From | Michael Gogins |
Subject | Re: [Cs-dev] Virtual machines for Csound |
Attachments | None None |
Are the faustgen opcodes available on Windows? Regards, Mike ===========================
Michael GoginsIrreducible Productions http://michaelgogins.tumblr.com Michael dot Gogins at gmail dot com On Mon, Nov 4, 2013 at 2:12 PM, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote: In relation to opcodes, I'd also like to note that Faust-written opcodes are running in Csound at near-native speeds |
Date | 2013-11-04 19:23 |
From | Victor Lazzarini |
Subject | Re: [Cs-dev] Virtual machines for Csound |
I don't know, did you package them? The code only depends on faustlib (from faust2 git) and LLVM. Victor On 4 Nov 2013, at 19:18, Michael Gogins wrote: > Are the faustgen opcodes available on Windows? > > Regards, > Mike > > > =========================== > Michael Gogins > Irreducible Productions > http://michaelgogins.tumblr.com > Michael dot Gogins at gmail dot com > > > On Mon, Nov 4, 2013 at 2:12 PM, Victor Lazzarini |
Date | 2013-11-04 19:32 |
From | Michael Gogins |
Subject | Re: [Cs-dev] Virtual machines for Csound |
Attachments | None None |
Oh right, I remember now. I did not package them because of the LLVM dependency. I have the feeling CLang is not up to speed on Windows... Regards, Mike =========================== Michael GoginsIrreducible Productions http://michaelgogins.tumblr.com Michael dot Gogins at gmail dot com On Mon, Nov 4, 2013 at 2:23 PM, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote: I don't know, did you package them? The code only depends on faustlib (from faust2 git) and LLVM. |
Date | 2013-11-04 19:37 |
From | Victor Lazzarini |
Subject | Re: [Cs-dev] Virtual machines for Csound |
That's a pity, it does work well on OSX & Linux. On 4 Nov 2013, at 19:32, Michael Gogins wrote: > Oh right, I remember now. I did not package them because of the LLVM dependency. I have the feeling CLang is not up to speed on Windows... > > Regards, > Mike > > > =========================== > Michael Gogins > Irreducible Productions > http://michaelgogins.tumblr.com > Michael dot Gogins at gmail dot com > > > On Mon, Nov 4, 2013 at 2:23 PM, Victor Lazzarini |