[pypy-dev] Questions Re: STM status

Andrew Francis andrewfr_ice at yahoo.com
Fri Feb 17 20:26:19 CET 2012

Hi Armin:

 From: Armin Rigo <arigo at tunes.org>
To: PyPy Developer Mailing List <pypy-dev at python.org> 
Sent: Thursday, February 16, 2012 3:58 PM
Subject: [pypy-dev] STM status
>An update for STM: today I managed to build a pypy using the new "stm
>gc".  It runs richards.py on tannit:

>in 1 thread: 2320 ms per iteration
>in 2 threads: 1410 ms per iteration
>in 4 threads: 785 ms per iteration
>in 8 threads: 685 ms per iteration

>The small gap between 4 and 8 threads is due to tannit having only 4
>"real" cpus, each one hyperthreaded.  The additional gain is thus
>smaller than expected.

This is really exciting stuff. As always I have a few questions.

1) I have been looking at the transaction module and its dependent modules.
In rstm.perform_transaction, I see a comment to a "custom GIL." So the GIL is still there? Or will it be eventually removed?

2) I have glanced over the transaction and rstm module (it would help if I understood PyPy's architecture better but I am working on that). I figured it would be best to focus on translator.transform.py and translator.llstminterp.py first to understand what is happening at a high level. 

I admit I am not comfortable with reading the code. However I see places where the code distinguishes between mutable and immutable, local and non local variables. I will assume mutable and non-local variables will be the subject of transactional memory. 

Although the STM implementation will be transparent to the programmer (there is only transaction.run() and transaction.add() available to the programmer), can I assume that one can "help" the STM if a) somehow more variables can be marked as immutable? 2)"Threads of execution" do not share state. Essentially a more functional programming approach.

Or am I reading too much into this?

3) Could the stackless module work with STM?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20120217/32ab8b4b/attachment-0001.html>

More information about the pypy-dev mailing list