The Emterpreter JavaScript As Byte Code
The Emterpreter JavaScript As Byte Code
Written by Ian Elliot   
Wednesday, 25 February 2015

This is one of those stories that, if you get what is really going on, might send you screaming for the comfort of a pillow. Does the programming world get any stranger?

asmjslogo

 

When you think about Emterpreter, the natural reaction is to get a strange feeling - much like the one you probably got when you first encountered a bootstrapping compiler, i.e. a compiler written in the language it compiles and can compile itself.

Alon Zakai the founder of the Emscripten, C to asm.js compiler, project has a very strange idea. He has modified Emscripten to convert asm.js to a bytecode format and emit a JavaScript interpreter for that byte code. Wait for a moment for this to sink in.

We take C/C++ code and convert it to asm.js a subset of JavaScript. Then we convert the asm.js to byte code and spit out an interpreter for it written in JavaScript. 

The JavaScript interpreter is loaded in the usual way into the web page and the bytecode is loaded as data. The big advantage of this scheme is that the byte code doesn't have to be parsed and this speeds up the entire load process. 

Reducing latency is the aim of this seemingly mad idea. When you load a large asm.js it has to be parsed and this means there is often a big gap between load and getting results. If you also use an ahead-of-time AOT compiler the latency is even bigger because the whole thing has to be compiled before it starts running. A test program took around 300ms to startup and with AOT this doubled to 600ms after page load. The same program as byte code started up in 150ms with AOT and slightly less without. 

Of course there is a cost. The Emterpreter code runs anything from six to twenty times slower. Clearly if you are using asm.js speed of execution is going to be important. A partial solution is to mark some routines as critical and leave them as asm.js. This minimises load time for the majority of the code but leaves the asm.js to run when it is needed. This works, but the best solution is to use a two-phase startup. First load emterpreted code and then load asm.js in the background. 

With this change we get a strange hybrid behavior. The code first loads in about 200ms but runs at about a fifth of the speed and then after 900ms we get back to full asm.js speed. 

 

emterpret

 

The whole Emterpreter idea is experimental, but you can try it out and see if the mix of low latency and eventual full performance works for you. Personally I'm still trying to cope with the idea of C/C+ to JavaScript, to byte code, run by a JavaScript interpreter. 

 

asmjslogo

Banner


Stack Overflow Reveals Hiring Trends
15/03/2017

Stack Overflow has collected data on changes in the developer hiring scene that will be really useful to anyone currently looking for a job. It shows that ReactJS and Docker are the fastest growing ta [ ... ]



//No Comment - Trojan of Things, Disk LEDs Leak Data & So Do Phone Magnetometers
02/03/2017

• Trojan of Things: Embedding Malicious NFC Tags into Common Objects 

• LED-it-GO: Leaking (a lot of) Data from Air-Gapped Computers via the (small) Hard Drive LED

• Mobile Phone Identifi [ ... ]


More News

 

 
 

 

blog comments powered by Disqus

Last Updated ( Wednesday, 25 February 2015 )
 
 

   
Banner
RSS feed of news items only
I Programmer News
Copyright © 2017 i-programmer.info. All Rights Reserved.
Joomla! is Free Software released under the GNU/GPL License.