Re: [pypy-dev] PyPy JIT & C extensions, greenlet

Hi Maciej: Message: 4 Date: Mon, 27 Sep 2010 14:23:14 +0200 From: Maciej Fijalkowski <fijall@gmail.com> Subject: Re: [pypy-dev] PyPy JIT & C extensions, greenlet To: "Ian P. Cooke" <ipc@srand.net> Cc: pypy-dev@codespeak.net Message-ID: <AANLkTinYC+Orf9RXfyST3ZJPX0ZM0nAXYsh=tH8PtAxK@mail.gmail.com> Content-Type: text/plain; charset=UTF-8
I talked briefly with Armin at EuroPython about Stackless and JIT. I poke around pypy-dev and use stackless.py. However I am very interested in learning about how the stackless transform works and how pypy works so I could help. I have been at Stackless for about five years now and I wouldn't mind spending a year learning pypy. Cheers, Andrew

Hi, On Wed, Sep 29, 2010 at 11:39 PM, Andrew Francis <andrewfr_ice@yahoo.com> wrote:
Maybe I should expand on an idea posted on #pypy by fijal. He mentioned that he would like to try to support Stackless in PyPy without using the stackless transform, just by using the same low-level stack hacks that are done by greenlet.c and optionally by Stackless Python. This means that there would be two different approaches we can consider to support Stackless in PyPy: stackless transform (done) C-level stack switching -------------------------------- -------------------------------- approach from Stackless Python 1 approach from Stackless Python 2 10-20% speed penalty in the no speed penalty whole interpreter JIT support needed JIT supports comes for free (missing so far) fully portable needs a little bit of assembler some issues to integrate with easy to integrate with C code non-PyPy C code tasklet-switching Python code tasklet-switching Python code becomes a single loop in becomes N loops with residual calls machine code to switch() functions (potentially very good) (less good) As you can see from the above summary, the main issue with the 2nd approach would be that Python tasklet-switching loops do not turn into a form that is as efficient as what we would get in the 1st approach. Nevertheless it is an interesting approach because it makes basic JIT support and integration easier. A bientôt, Armin.

Re-hi, I forgot to mention that the improvement over the "stackless transform" approach for PyPy might be to not apply the stackless transform on the interpreter, but replace it with resuming C code using the blackhole interpreter that we have anyway in the JIT. Also, any "final" long-term approach that anyone should at least consider if taking all of this seriously might be a mix of the two approaches, similar to Stackless Python 3 which combines both Stackless Python 1 and Stackless Python 2 features. Armin

Hi, On Wed, Sep 29, 2010 at 11:39 PM, Andrew Francis <andrewfr_ice@yahoo.com> wrote:
Maybe I should expand on an idea posted on #pypy by fijal. He mentioned that he would like to try to support Stackless in PyPy without using the stackless transform, just by using the same low-level stack hacks that are done by greenlet.c and optionally by Stackless Python. This means that there would be two different approaches we can consider to support Stackless in PyPy: stackless transform (done) C-level stack switching -------------------------------- -------------------------------- approach from Stackless Python 1 approach from Stackless Python 2 10-20% speed penalty in the no speed penalty whole interpreter JIT support needed JIT supports comes for free (missing so far) fully portable needs a little bit of assembler some issues to integrate with easy to integrate with C code non-PyPy C code tasklet-switching Python code tasklet-switching Python code becomes a single loop in becomes N loops with residual calls machine code to switch() functions (potentially very good) (less good) As you can see from the above summary, the main issue with the 2nd approach would be that Python tasklet-switching loops do not turn into a form that is as efficient as what we would get in the 1st approach. Nevertheless it is an interesting approach because it makes basic JIT support and integration easier. A bientôt, Armin.

Re-hi, I forgot to mention that the improvement over the "stackless transform" approach for PyPy might be to not apply the stackless transform on the interpreter, but replace it with resuming C code using the blackhole interpreter that we have anyway in the JIT. Also, any "final" long-term approach that anyone should at least consider if taking all of this seriously might be a mix of the two approaches, similar to Stackless Python 3 which combines both Stackless Python 1 and Stackless Python 2 features. Armin
participants (2)
-
Andrew Francis
-
Armin Rigo