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

[Paolo Giarrusso]

On Sat, Jan 3, 2009 at 15:12, Armin Rigo <arigo at tunes.org> wrote:
> Hi,

> Your writing style is too annoying to answer properly :-(

Sorry for that, I don't usually do it. I'm trying to do advocacy of my
position, but sometimes I realize there's a subtle boundary with
flaming; and most of that flaming is actually addressed to CPython
developers.

> I will not try to answer all of the points you mention;
> instead, let's just point out (as others have done) that
> the picture is more complex that you suppose, because it
> includes a lot of aspects that you completely ignore.

Tradeoffs are always involved, but in lots of cases, in the Python
community, misaddressed concerns about simplicity of the Python VM,
and ignorance of literature on Virtual Machines, lead to mistakes. And
I think we mostly agree on the facts underlying this statement, even
if we express that with different harshness.

I don't claim to be an expert of VM development, not at all.
But since there is a big disagreement between what I learned during 3
months of lessons (which was a first course on VM development) and
CPython, either one is wrong; my professor suggests that the Python
side is wrong and that implementers of Smalltalk, Self, and other
languages have some point. And all the evidence I could find
(including your project) agrees with that, on topics like:

- threading in the interpreter
- garbage collection vs reference counting
- tagged pointers
- hidden classes (i.e. V8 maps, which mostly date back to the early '90s).

If anybody is interested, this is the homepage of the course, with the
needed references (most of the links to papers are not directly
accessible, but the papers can be downloaded from other sources):

http://www.daimi.au.dk/~amoeller/VM/

== __DEL__ SEMANTICS ===

> I
> know definitely that with changes to the semantics of the
> language, Python could be made seriously faster.

> PyPy is
> not about this; it's a collection of people who either
> don't care too much about performance, or believe that
> even with these semantics Python *can* be made seriously
> fast -- it's just harder, but not impossible.

Just to make sure: I don't advocate changing semantics which have
value for the programmer; I advocate changing semantics when they have
problems anyway, like for this case, or for the int/long distinction,
which created problems both for tagged integers and for implementers.

Those two posts pointed out by Carl are interesting:

http://morepypy.blogspot.com/2008/02/python-finalizers-semantics-part-1.html
http://morepypy.blogspot.com/2008/02/python-finalizers-semantics-part-2.html

I'm interested about the costs of guaranteeing destructor calls in
topological order, I might reconsider my position on that particular
point; however, "topological-order-unless-a-cycle-is-found" is IMHO a
worse semantics than "no-topological-order", and that's what actually
matters, because it complicates implementation without being easier to
use correctly, because using fields requires proving that the object
cannot be part of a cycle, and that requires in turn an analysis of
the internals of other objects; this shouldn't be required to the
programmer since data hiding mostly forbids relying on this.

It would maybe be more useful to implement "reverse topological order"
and to clear all pointers to children of an object, to make sure that
nobody tries to rely on undefined behaviour, at least for Java, but
maybe also for Python.

=== SUMMARY ===
So, the full Python semantics (i.e. __del__ is like a C++ destructor)
are surely easier to use than Java/.NET finalizers, and are safe,
because one cannot get NULL pointers; but they have for the huge
problem of memory leaks; I'm undecided about
"topological-order-unless-a-cycle-is-found"; Java finalizers are
something that nobody should use; Python weakrefs still allow
resurrection, which causes slowdown as documented by Boehm; Java
weakrefs involve a fair amount of boilerplate code and they also
require the programmer to decide where the reference queue should be
polled, but at least they are quite difficult (if not impossible) to
misuse.

Regards
-- 
Paolo Giarrusso