Thursday, December 23, 2010

Is the Web Ready for Compiled Code?

CPython compiled to JavaScript is now reasonably fast on Firefox 4 and Chrome. Startup takes a few seconds, but it could be done in a web worker, so as not to stall a loading page. Executing code afterwards is far slower than native CPython, but already fast enough to be useful for some things, and getting faster all the time. (There are other limitations, like importing of modules, but I'm mainly focusing on speed for now.) So, from the perspective of those two browsers, we might be able to use Python on the web.

However, for it to make sense in general, it needs to work well on all or almost all browsers people use. So, what's the situation with other browsers?
  • The Python demo tends to run very slowly in older browsers, that don't have a modern JavaScript engine. But, those people will upgrade eventually, so this will be solved (except perhaps for a minority using IE6...).
  • Currently Python will not run on Opera, due to a bug in their JS engine. They have been notified of the problem. As Opera has a quite fast JS engine, I am hopeful that compiled code will work there at some point.
  • IE9 has a fast JS engine as well, but I don't have a Windows machine to test on. Has anyone tried to run the Python demo there? Update: Issue 22.
  • Safari has had a fast JS engine for a while (these days perhaps not as fast as the other open source ones, given recent speedups in Firefox and Chrome, but still quite good). As in the previous point, I lack a machine to test on - has anyone tried there? Update: Works in Safari and even iPads.

Saturday, December 18, 2010

Emscripten 0.7!

Main changes in this release:
  • Lots of minor fixes and additions, in order to get CPython working. As a result there is now a web demo of Python, which seems to work quite well aside for being very slow in Chrome.
  • Figuring out what to do with LLVM optimizations. It looks like all of them generate suitable code except for -instcombine, which apparently combines instructions in a CPU-specific way (so, it isn't portable, and confuses Emscripten). All the tests now pass with LLVM optimizations enabled (all but the problematic one just mentioned).
So, not much in the way of new features: As mentioned before, we are already pretty much feature complete at this point.

Sunday, December 12, 2010

Python Demo

With help from rasjidw, there is now a web demo of Python. Check it out, and let me know if you find a bug!

The demo is of CPython, the original/standard Python implementation, compiled from C to JavaScript. What's cool about compiling CPython itself is that we get all the language features 'for free', both the common stuff you'd expect and think of first, and also things that if you were writing a new implementation, you might leave for last.

Known limitations:
  • No import of modules - just the core language works. It should be possible to get imports working, of both C modules and Python ones, but it would require writing code for dynamic linking etc.
  • I tested in Firefox 4 beta and Chrome 8, and for some reason the demo runs very slowly in Chrome 8 (perhaps related to V8 Issue 947?). Firefox 4 runs much faster but still obviously slower than native CPython. In any case that should improve once we get LLVM optimizations working.

Saturday, December 11, 2010

A Ridiculously Recursive Bug

Work has been going on to get Emscripten to compile CPython (the standard implementation of Python) into JavaScript. It's very close to working, so I started to write an automatic test. But the test failed even though running the test manually worked.

That's weird, I thought.

Turns out that something quite amusing was happening. The automatic test system and other scripts are written in Python, and the test runner checks for script crashes and failures by scanning for the text that appears in a Python stack trace, which is to say something like 'Traceback (most recent call last)' etc.

Now, when Emscripten compiles Python itself, it generates JavaScript code that includes, unsurprisingly, all the constant strings in Python - including that very string! So the right output was erroneously detected as a failure.

I guess that's what can happen if your test compiles the very same runtime in which the test infrastructure is built... ;)