Is Unladen Swallow dead?

[Carl Banks]

On Nov 18, 2:59 pm, Jean-Paul Calderone <calderone.jeanp... at gmail.com>
wrote:
> On Nov 18, 1:31 pm, John Nagle <na... at animats.com> wrote:
>
>
>
>
>
> > On 11/18/2010 4:24 AM, BartC wrote:
>
> > > "John Nagle" <na... at animats.com> wrote in message
> > >news:4ce37e01$0$1666$742ec2ed at news.sonic.net...
> > >> On 11/16/2010 10:24 PM, swapnil wrote:
>
> > >>> AFAIK, the merging plan was approved by Guido early this year. I
> > >>> guess Google is expecting the community to drive the project
> > >>> from here on. That was the whole idea for merging it to mainline.
> > >>> From my last conversation with Collin, they are targeting Python
> > >>> 3.3
>
> > >> I think it's dead. They're a year behind on quarterly releases.
> > >> The last release was Q3 2009. The project failed to achieve its
> > >> stated goal of a 5x speedup. Not even close. More like 1.5x
> > >> (http://www.python.org/dev/peps/pep-3146)
>
> > > There must have been good reasons to predict a 5x increase.
>
> >      For Java, adding a JIT improved performance by much more than that.
> > Hard-code compilers for LISP have done much better than 5x.  The
> > best Java and LISP compilers approach the speed of C, while CPython
> > is generally considered to be roughly 60 times slower than C.  So
> > 5x probably looked like a conservative goal.  For Google, a company
> > which buys servers by the acre, a 5x speedup would have a big payoff.
>
> > > Assuming the 5x speedup was shown to be viable (ie. performing the
> > > same benchmarks, on the same data, can be done that quickly in any
> > > other language, and allowing for the overheads associated with
> > > Python's dynamic nature), then what went wrong?
>
> >       Python is defined by what a naive interpreter with late binding
> > and dynamic name lookups, like CPython, can easily implement.  Simply
> > emulating the semantics of CPython with generated code doesn't help
> > all that much.
>
> >       Because you can "monkey patch" Python objects from outside the
> > class, a local compiler, like a JIT, can't turn name lookups into hard
> > bindings.  Nor can it make reliable decisions about the types of
> > objects.  That adds a sizable performance penalty. Short of global
> > program analysis, the compiler can't tell when code for the hard cases
> > needs to be generated.  So the hard-case code, where you figure out at
> > run-time, for ever use of "+", whether "+" is addition or concatenation,
> > has to be generated every time.  Making that decision is far slower
> > than doing an add.
>
> This isn't completely accurate.  It *is* possible to write a JIT
> compiler
> for a Python runtime which has fast path code for the common case, the
> case
> where the meaning of "+" doesn't change between every opcode.  PyPy
> has
> produced some pretty good results with this approach.

Right.  The key is to be able to dispatch on the type of object once
for a given chunk of code, which is possible if you do some kind of
flow path analysis on the function/chunk.

PyPy is starting to look much better of late, I kind of thought their
first approach was wrong (or at least too much) but they seem to have
pushed though it.


Carl Banks