jessenoller.com

Slides from my intro to Concurrency/Distributed sys­tems talk @pycon 2009 are here. Also up on the pycon site here

Slides from my intro to Concurrency/Distributed systems talk @pycon 2009 are here. Also up on the pycon site here

Slides from my intro to mul­ti­pro­cess­ing talk @pycon 2009 are here. Also up on the pycon site here

Slides from my intro to multiprocessing talk @pycon 2009 are here. Also up on the pycon site here

So, by now some par­tic­u­lar set of peo­ple (mainly those at the VM-Summit and twit­ter) have heard about unladen-swallow, a new project out of “the Google” which is work­ing on pro­vid­ing some seri­ous speed increases to the CPython interpreter.

This is being worked on by Collin Win­ter, Jef­fery Yasskin and Thomas Wouters — it’s a branch of CPython: Not a Fork. Some of the improve­ments could pos­si­bly be rapidly inte­grated to python-trunk, some of them (such as using LLVM) are a longer road obvi­ously, but given the peo­ple involved, and oth­ers in that arena, I could eas­ily see this sup­plant­ing the cur­rent inter­preter quickly.

But I’m biased, because they sped up CPickle (which is what mul­ti­pro­cess­ing uses for shar­ing data between processes). Oh, and they include psyco (port to 64 bit ok please).

The goals are nice, quot­ing 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 appli­ca­tions to switch to Unladen Swallow.

1. Pro­duce a ver­sion of Python at least 5x faster than CPython.
2. Python appli­ca­tion per­for­mance should be stable.
3. Main­tain source-level com­pat­i­bil­ity with CPython applications.
4. Main­tain source-level com­pat­i­bil­ity with CPython exten­sion modules.
5. We do not want to main­tain a Python imple­men­ta­tion for­ever; we view our work as a branch, not a fork.

And (from 2009 Q3 Goals):

In addi­tion, we intend to remove the GIL and fix the state of mul­ti­thread­ing in Python. We believe this is pos­si­ble through the imple­men­ta­tion of a more sophis­ti­cated GC sys­tem, some­thing like IBM’s Recy­cler (Bacon et al, 2001).

Our long-term goal is to make Python fast enough to start mov­ing performance-important types and func­tions from C back to Python.

The great thing is: They have a work­ing imple­men­ta­tion right now. Yessir, it’s not vapor! Hooray!

I’ve got it down, com­piled and I’m futz­ing around with it now, yes it works. Unfor­tu­nately test­ing it I found a bug in mul­ti­pro­cess­ing (not unladen). Damn!

So, 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 ...

In a com­plete tan­gent from my numer­ous other projects, I’ve had a few peo­ple ask me recently about python on the mac, how to get started/etc.

I’m going to solely focus on python in Leop­ard (10.5.x) and not any­thing before that. Any­thing before that is dead to me! DEAD!

» Read the rest of this entry «

In a complete tangent from my numerous other projects, I've had a few people ask me recently about python on the mac, how to get started/etc. I'm going to solely focus on python in Leopard (10.5.x) and not anything before that. Anything before that is dead to me! DEAD! If you open a shiny new macbook, ...