Scrawls from Preston...

Powered by Pelican.

Tue 09 April 2013

asm.js and Python in the Browser

There has been a fair amount of recent coverage about asm.js since it started appearing in the nightly builds of Firefox. There are other places to read more about what asm.js - but essentially you can think of it as a subset of javascript that is functionally somewhat like assembly as far as the way it allows for conversion to hardware instructions with minimal interpretation.

A couple good pro/con articles on it are here:

I'm willing to wait and see how asm.js plays out. For one, I completely disagree with one of the points made by mraleph. The point being that people will someohow abandon writing dynamic and expressive JS and start writing asm.js by hand to target the higher performance. If this were the case, then people wouldn't bother at all with Python or Ruby, as all the things would be written in C.

There is a time and a place to optimize, the fact that these times and places can be chosen incorrectly shouldn't mean that alternate techniques for optimization should not be available.

Really one of the key advantages of something like this is enabling C to be "ported" to asm and run in the browser. Not only because of the performance gained, but because it is already written. Python benefits from this all the time by being able to call C code. Yes, mostly this is chosen under the goal of performance, but with pypy that argument holds less water. However there will always be the reason of "because it is already done".

The first demo area the asm folks are pushing is being able to run graphics intensive game engines in the browser This involves running the game engine originally written in C(++), in a JS VM via asm - and mapping calls from openGL to webGL (which in turn, uses openGL). What I'm surprised by is that nobody seems to be explicitly saying what seems apparent to me: this isn't about running things in the browser - Mozilla has to be looking at this for FirefoxOS. You can't have a mobile OS platform without a game story, and a way to build apps with snappy UIs in general. If FirefoxOS is to be based around a web UI - they need a way to get games on the platform, the speed in the "browser" is, I'm guessing, just a side benefit.

One other side benefits just might be "Python in the Browser".

Now I can mostly pull my own weight writing JS when I have to (if I haven't written a much in a while, it usually takes me a bit to dust off those braincells). But as a die-hard Python fan, I lament that multiple languages weren't supported at the dawn of JS in the early browsers, and that we've ended up with a mono-culture of browser based scripting in the form of javascript-only.

There are several projects that attempt to bring Python to the browser, I'm going to talk about what I see as the main two (if you know of other mature ones I've missed, fill me in via the comments). is a polyglot shell-in-a-browser site that uses asm.js via emscripten to actually run CPython in the browser. This has the advantage of being a complete implementation, but is more or less unoptimized in any way.

The other is the skulpt project, which can be tried out here: which has found some great usage among online python programming classes.

Now it would be unfair to expect either of these implementations to hold a candle to CPython or Pypy running directly on hardware - but there are any number of applications where it could easily be "fast enough".

There are a few things that would need to be sorted out for any real use of Python in the browser (as opposed to an isolated Python island running in the browser). First would be support for source maps to allow runtime debugging of Python code. The other would be some form of being able to call functions across the Python/JS divide and/or some access to the DOM from the Python side.

Using this super brain-dead simple benchmark

import time
start = time.time()
d = {}
for i in range(100000):
    d[i] = 'f'
print time.time() - start

We get the following, mostly meaningless, results:

On my late 2008 MBP with CPython: 0.036 seconds

In in Chrome: 7.706 seconds

In in Firefox nightly - with special ASM support: 3.107 seconds

With Skulpt Chrome via codeskulptor: 0.414 seconds

Clearly we are dealing with orders of magnitudes of difference, and the benchmark is clearly silly enough that I'm not trying to draw any firm conclusions about overall performance. But I think there is a chance - just a chance, that Python in the browser may one day be "fast enough" for some interesting applications. In the meantime it offers a great educational tool for online instruction and "test drive" shell-in-a-browser tool.