[pypy-dev] Haswell System

[Armin Rigo]

Hi all,

(sent for the pypy-dev mailing list)

A quick status update about STM.  As I've said on IRC, I am *again*
looking at a new approach.  This would change the core of STM, but
lets us keep most of the work we did on top of it, i.e. inside PyPy
and PyPy's JIT.

The pre-prototypes (called "c5" and "c6") as well as the current draft
(called "c7") tell me that it might work, and it might work very well
indeed, with a rather minor overhead.  I cannot estimate the
percentages yet, but it's certainly much better than a 2x slow-down
--- more like 20%.  The ideas apply better to low numbers of CPUs,
which is fine for the most common current-generation machines; it
would make using only two threads a big win already.

See README.txt for details here:
https://bitbucket.org/pypy/stmgc/raw/c7/c7 .  Sorry if it's written in
a terse style.  The basic limitation is that it can only work on
64-bit Linux.

If you're interested and by any chance you're near Neuchatel,
Switzerland, next Thursday 9th Jan, I'm sure Patrick and Pascal
wouldn't oppose you showing up at 11 at the University for this
presentation:

> """
> PyPy is a Python interpreter written in Python, best known for being
> often several times faster than the standard CPython.  It is also a
> ground for experimenting with language implementation ideas (for
> Python and others).  One such experiment uses STM to replace the
> global interpreter lock, in the now-well-published manner; plus some
> language design ideas about how to allow the end programmer to obtain
> longer, controlled transaction.
>
> I'll describe the current ideas for a very cheap STM design that
> focuses on this case: it is object-based, with an integrated GC;
> transaction lengths from medium to huge (several full GC cycles); no
> false conflicts; and focusing on low numbers of cpus for now.  The
> current ideas seem to allow for a "read barrier" that is not a barrier
> at all, but only 2 to 4 cpu instructions that the machine can schedule
> in parallel, and that don't prevent regular compiler optimizations.
> (This relies on a Linux-only system call, though.)  Additionally, this
> could potentially be extended with HyTM.
> """


A bientôt,

Armin.