[pypy-dev] http://code.google.com/p/unladen-swallow/wiki/ProjectPlan

Paolo Giarrusso p.giarrusso at gmail.com
Mon Mar 30 01:28:31 CEST 2009

On Thu, Mar 26, 2009 at 02:42, Leonardo Santagada <santagada at gmail.com> wrote:
> On Mar 25, 2009, at 9:27 PM, Christian Tismer wrote:
> > Hi friends,
> >
> > please have a look at this.
> > http://code.google.com/p/unladen-swallow/wiki/ProjectPlan
> >
> > is this YAIPAP ?
> > Yet Another Ignorant Python Acceleration Project
> >
> > I see them mentioning Hölzle and Self, and I see a reference to
> > Psyco where they want to steal from, but PyPy does not exist.
> >
> > IMHO, this is totally GAGA  - chris

First, I suggest you have a look at the FAQ - when I did, I discovered
the developers are full-time Google engineers. Having said that, the
Google V8 group does not seem to be involved, and that's quite stupid.
However, I studied with Lars Bak and the base ideas he had are the

Missing knowledge of PyPy is also stupid obviously, but I wonder why
nobody proposed "hey, let's tell them"; fighting another project.
They'd sure benefit, for instance, from CALL_METHOD and
CALL_LIKELY_BUILTIN ideas (they mention among their purposes fixing
the performance problems addressed by CALL_LIKELY_BUILTIN, that's why
I mention these).

Also, they're already started with releasing. Have a look at their benchmarks:

Did you look at that because declaring it GAGA?

> I was reading it earlier, the simpler ideas, like making pickle faster
> and most of q1 deliverables seems nice, and could really help python
> right now, but those seems more like the things Need For Speed sprint
> was doing.

I don't know about Need For Sprint, but my first guess is that this
maybe happens because, as pointed out various ways, CPython has lots
of "obvious" deficiencies.

> Not the LLVM-JIT, new GC, eliminate the GIL seems
> unrealistic, even the pace of the project seems to be counting on tons
> of new developers joining the project after the Q1 milestone.

Well, the milestones seem crazy but they did achieve something notable
in their Q1 deliverable, but most of the ideas seem correct.
"Eliminate the GIL" is not hard by itself, the problem (IMHO, no hard
numbers for that) is that it's impossible with refcounting (because of
the cost of atomic refcount manipulation). The author of the old "free
threading" patch mentioned only another problem, that is locking
around name lookups in mutable name dictionaries (for looking up
object members, globals, etc.), which can also be approached (and I
think refcount manipulation is a bigger issue).

Paolo Giarrusso

More information about the Pypy-dev mailing list