John Nagle <na...@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. -- http://mail.python.org/mailman/listinfo/python-list
