Pycon: Unladen-Swallow


Tree-Swallow.jpgSo, by now some particular set of people (mainly those at the VM-Summit and twitter) have heard about unladen-swallow, a new project out of “the Google” which is working on providing some serious speed increases to the CPython interpreter.

This is being worked on by Collin Winter, Jeffery Yasskin and Thomas Wouters – it’s a branch of CPython: Not a Fork. Some of the improvements could possibly be rapidly integrated to python-trunk, some of them (such as using LLVM) are a longer road obviously, but given the people involved, and others in that arena, I could easily see this supplanting the current interpreter quickly.

But I’m biased, because they sped up CPickle (which is what multiprocessing uses for sharing data between processes). Oh, and they include psyco (port to 64 bit ok please).

The goals are nice, quoting a few choice ones from the project plan:

We want to make Python faster, but we also want to make it easy for large, well-established applications to switch to Unladen Swallow.

  1. Produce a version of Python at least 5x faster than CPython.
  2. Python application performance should be stable.
  3. Maintain source-level compatibility with CPython applications.
  4. Maintain source-level compatibility with CPython extension modules.
  5. We do not want to maintain a Python implementation forever; we view our work as a branch, not a fork.

And (from 2009 Q3 Goals):

In addition, we intend to remove the GIL and fix the state of multithreading in Python. We believe this is possible through the implementation of a more sophisticated GC system, something like IBM’s Recycler (Bacon et al, 2001).

Our long-term goal is to make Python fast enough to start moving performance-important types and functions from C back to Python.

The great thing is: They have a working implementation right now. Yessir, it’s not vapor! Hooray!

I’ve got it down, compiled and I’m futzing around with it now, yes it works. Unfortunately testing it I found a bug in multiprocessing (not unladen). Damn!

  • Sounds interesting. Hopefully they can get things working nicely and in as stable way as possible. Hopefully this can increase amount of interest people have in learning of Python.
  • Luis
    @Michael: Where did you get that? Could you tell us more about this being used in Youtube??
  • So how does this relate to Parrot?
  • It doesn't really relate to Parrot. This is a branch of CPython. The implementation of Python on Parrot is called Pynie but there is a long way to go with it.
  • They are similar in that both are targeting new virtual machines, are they not? I don't know how similar they are (or aren't). I know both are registered based.
  • Parrot *is* a Virtual machine - for running multiple languages. The Python port for Parrot (Pynie) is very young. unladen-swallow is an attempt (amongst other things) to integrate parts of the LLVM into core CPython to provide a speedup. They are unrelated projects with different goals - but there is a VM involved in both...
  • The cool thing is that Unladen swallow has been serving YouTube traffic since last Friday!
  • neuruss
    Please tell us more !! Where did you get that??
  • From the google guys who announced unladen-swallow at the Python VM summit at PyCon.
  • Luis
    Please tell us more! Where did you get that??
  • that's pretty cool. PyPy is already targeting LLVM, afaik, i don't know why they didn't just donate a lot of work to PyPy.

    also i'm not sure why multithreading is so important. the GIL applies to threads, but not to processes. just use the the pp module or similar. i haven't done much parallel programming but they always scream in #python never to use threading because any kind of scaling introduces really hard-to-track bugs. i think they favor IPC over shared memory.

    for a python implementation the main thing i'd be concerned with is mostly eliminating hash table lookups for attributes. i wonder if their project does that.
  • PyPy is a lot more, and a lot less than what they're trying to do. PyPy is a complete re-implementation of "the world" - unladen swallow is performance enhancements. Also, AFAIK, they dropped the LLVM work.

    Also, Hi, I'm the multiprocessing module maintainer (parallel programming with processes in python 2.6), too. As for #python hating threads: not everyone has a rational view on threads vs. processes vs everything else. There's a place in the world for both.
  • Martin
    Wow. Seems very professional. Will be interesting to follow the development.
  • Paul Boddie
    Interesting figures on the "Releases" page, although I'm not sure about their speed-up terminology:

    1.023 -> 0.409: 150.36% faster

    Surely, if the figures on the left are times, the speed-up is around two-fold in this case. Personally, I dislike the combination of percentages with superlatives - one should say "40% of the original time" or "2.x of the original speed".

    Anyway, let's wait for it to get into (someone's edition of) the shootout. ;-)
  • llimllib
    They say on that page that the times are calculated as (new-old)/new, so (.409 - 1.023) / .409 = -1.5 -> 150%

    I agree that this is silly; .409 is 2.5 times faster than 1.023, not 1.5 times.
  • aono
    100% faster == 2x speedup. 150% faster == speedup of 2.5

    I agree that 'speedup' is the correct metric, but a lot of people dont get it, and x% faster should convey what they want. Its just not immediately obvious with 150%, though it would with 100%
  • Drop an email to their list and ask for a clarification
blog comments powered by Disqus