[pypy-dev] Threaded interpretation (was: Re: compiler optimizations: collecting ideas)

[Armin Rigo]

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.