Hi Paolo, On Thu, Dec 25, 2008 at 12:42:18AM +0100, Paolo Giarrusso wrote: > If I'll want to try something without refcounting, I'll guess I'd turn > to PyPy, but don't hold your breath for that. The fact that indirect > threading didn't work, that you're 1.5-2x slower than CPython, and > that you store locals in frame objects, they all show that the > abstraction overhead of the interpret is too high.
True, but a 1.5x slowdown is not a big deal on many application; the blocker is mostly elsewhere. And on the other hand, we've been working on the JIT generator -- since a while now, so I cannot make any promise -- and the goal is to turn this slowish interpreter into a good JITting one "for free". As far as I know, this cannot be done so easily if you start from a lower-level interpreter like CPython. This is our "real" goal somehow, or one of our real goals: a JITting virtual machine for any language that we care to write an interpreter for. > 3) still, I do believe that working on it was interesting to get > experience about how to optimize an interpreter. Sure, it makes some sense if you think about it in this way. I doesn't if you think about "I want to give the world a fast Python interpreter", but you corrected me already: this is not your goal, so it's fine :-) > And the original idea was to show that real multithreading (without a > global interpreter lock) cannot be done in Python just because of the > big design mistakes of CPython. I disagree on this point. Jython shows that without redesign of the language, they can implement a real multithreading model without a GIL. About PyPy, the lesson that we learned is different: it's that implementing a GIL-free model requires a bit of tweaking of the whole interpreter -- as opposed to doing it in a nicely separable manner. So far we only implemented threads-with-a-GIL, which can be done in this separable way (i.e. without changing a single line of most of the interpreter). Given enough interest we can implement full GIL-free multithreading the slow way: by going over most features of the interpreter and thinking. Note that it would also be possible to do that in CPython (but it would be even more work). It's just that doing so is not really "in the spirit" of PyPy :-) In our style, we would rather start by thinking harder about some unpolished ideas that float around about doing it in a separable manner anyway -- but this has not been tried at all. A bientot, Armin. _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
