a basic bytecode to machine code compiler

Sat Apr 2 17:32:00 EDT 2011

John Nagle <nagle at animats.com> writes:
> There's no easy way to speed up Python; that's been tried.
> It needs either a very, very elaborate JIT system, more complex
> than the ones for Java or Self, or some language restrictions.

Is it worse than Javascript? Tracemonkey and its descendants produce
pretty fast code, I think.
> The main restriction I would impose is to provide a call that says:
> "OK, we're done with loading, initialization, and configuration.
> Now freeze the code." At that moment, all the global
> analysis and compiling takes place. This allows getting rid
> of the GIL and getting real performance out of multithread CPUs.

That's quite an interesting idea. I do think a lot of production Python
code implicitly depends on the GIL and would need rework for multicore.
For example, code that expects "n += 1" to be atomic, because the
CPython bytecode interpreter won't switch threads in the middle of it.