a basic bytecode to machine code compiler

[Paul Rubin]

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.