Reimplement core bytecode engine in ASM.js

[freakboy3742]

The current bytecode engine works, but is not especially fast. One option for improving performance would be to re-implement the core bytecode interpreter in ASM.js - a subset of javascript that is known to run fast.

It isn't clear if the easiest way to implement this would be:

• a by-hand creation of a bytecode engine
• converting a C version of a bytecode engine using emscripten
• converting a Python version of a bytecode engine using a custom compiler.

This is a big project that will require further exploration.

[abonie]

Hi,

I will gladly investigate this topic and consider writing a proposal for GSoC. In this context, since this is described as big project, what would you say to be an appropriate goal to set? Would a PoC be enough? I just want to get a sense of what expectations you guys might have at this point, obviously will do research of my own and get better idea of what is doable for me.

On this note, choosing between this project and implementing part of the standard library, which would you rather see realized as a GSoC project?

[freakboy3742]

I'd expect a bit more than just a POC - but I certainly wouldn't expect the result to be "production ready" or anything like that. It would definitely need to be enough to prove that the idea was viable, and worth spending more time on.

As for the "preferred" project - both would be equally welcome. That said, the bar for being accepted on this project would be much higher than that for implementing part of the standard library. Implementing the standard library is relatively straight forward - it's re-implementing a public interface that's well documented, and easy to test. Implementing a bytecode machine is a lot more complex, so we're going to need to be convinced that you're up to the task before we accept you on such a project.

[ethanhs]

People have gotten CPython to compile to asm.js (see https://github.com/jallwine/emscripten_test/wiki/Compiling-python-with-emscripten for an example). There is also PyPyJS, which instead of jitting Python to machine code, jits to asm.js. An update to use webassembly might be interesting.

[freakboy3742]

I'm well aware of both of those projects; getting either to web assembly should be no more than a compiler flag.

However, they also carry a lot of overhead in their use. You end up moving the full compiler and interpreter toolchain - which isn't a small chunk of code. And, if you're just using Python to implement in-browser logic, you don't need a full REPL.

So - the proposal for this ticket is to implement just the bytecode machine - hopefully a much smaller payload.

[ethanhs]

I expected you would be, just wanted to share prior art for others 😃 I too am interested in submitting to work on this for the GSOC, but I don't want to step on the toes of @abonie. I was thinking something based on CPython's bytecode engine (since it is the reference implementation), and I would write in C++ so one could use ASM.JS or WASM (based on how you want to compile, and what your browser supports).

[freakboy3742]

Sure - understood.

I'm less bullish on emscripten and compiling C because it carries a lot of overhead; IIRC, "hello world" is something like 100k.

I'm actually much more interested in the approach described by #414 - that would target ASM.js/WASM directly, which VOC has shown can be quite viable as an approach.

[abonie]

@ethans Don't worry about stepping on my toes. I think it is only fair that everyone gets a shot. Also I am not going to submit a proposal for this particular issue anyway ;)