|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?
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.
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.
To be informed about new articles on I Programmer, install the I Programmer Toolbar, subscribe to the RSS feed, follow us on, Twitter, Facebook, Google+ or Linkedin, or sign up for our weekly newsletter.
or email your comment to: email@example.com
|Last Updated ( Wednesday, 25 February 2015 )