Mailman 3 March 2014 - pypy-dev

Possibly a PyPy C-API bug
by Johan Råde 09 Mar '14

09 Mar '14

Hi everyone, I think I might have found a bug in the PyPy C-API. It seems that PyType_Type.tp_new is broken. Here is a minimal example that reproduces the bug. Instructions: Compile Foo3.c as a python extension module named Foo3. Set up the paths so that Test3.py can find Foo3. Run Test3.py Expected result and observed result with CPython 2.7.6: Test3.py runs Observed result with PyPy 2.2.1: Test3.py crashes. (It gets into an infinite recursive loop where PyType_Type.tpnew and Foo3Type_Type.tp_new keep calling each other.) Fixing this bug, or finding a workaround, would get me one step closer to getting PySide to run with PyPy. Cheers, Johan

2 1

pypy 2.2.1 win32
by norbert.raimund.leisner＠arcor.de 07 Mar '14

07 Mar '14

Hello support-team, I have installed pypy 2.2.1 win32 for my OS Windows XP SP 3 -32 bit, Python 2.7, MSI Microsoft Visual C++ 2008 SP1 Redistributable Package (x86). Now my question: Must be Python 2.7 deinstalled and replaced by Pythonv2.7.6 or not? I ask you because a chess program "Sunfish" https://github.com/thomasahle/sunfish/ is using pypy. Best wishes, Norbert

4 6

RPython question about the lifetime of global state
by Lenard Lindstrom 06 Mar '14

06 Mar '14

Hi everyone, I am developing a new image blit system for Pygame 2.0 - the SDL2 edition. A blitter prototype project is maintained at https://bitbucket.org/llindstrom/blitter. The prototype implements a blit loop JIT; Pixel format specific blit code is generated dynamically as needed. The prototype is written in RPython as an interpreter for executing array copies. The JIT comes automatically from the RPython tool chain, of course. The prototype blitter is built as a stand-alone shared library with flags -Ojit --gcrootfinder=shadowstack. It has no Python dependencies. There are two entrypoint C functions, both decorated with rpython.rlib.entrypoint.entrypoint. Python side code uses CFFI to access the library. The library is initialized with a single call to rpython_startup_code at load time. The blitter library is meant to be an embedded interpreter, with initialize, configure, and execute functions. So my question, does the RPython tool chained explicitly support embedded interpreters? I ask because I have only seen secondary entry points used as callbacks into an interpreter (PyPy's cpyext interface). So I wish to confirm that the lifetime of an RPython global namespace, the JIT caches, and the garbage collector are that of the loaded library, and not just that of an entry point function call. Thanks in advance, Lenard Lindstrom

2 1

Re: [pypy-dev] RinohType and PyPy2
by Armin Rigo 02 Mar '14

02 Mar '14

Hi Brecht, On 1 March 2014 23:34, Brecht Machiels <brecht(a)mos6581.org> wrote: > While PyPy2 performs better than PyPy3, it's still much slower than CPython. Is RinohType hitting a weak spot in PyPy? Any hints on what I can do to improve performance? It's not really helpful, but the warm-up time is the first issue here. If I edit template.py to run it e.g. 10 times instead of only once, the speed grows quickly by a factor of 4. It means your code, for some reason, exhibits slow warm-ups (not the worst we've seen, but I agree it's a lot). It would be interesting to know if you have a similar speed-up when processing a single 10-times-larger document instead of 10 times the same small document :-) A bientôt, Armin.

1 0

pypy in python3?
by Martin Matusiak 02 Mar '14

02 Mar '14

Hi, I'm wondering whether there are any plans to port pypy itself to python 3 at some point. And what the benefits of that might be (other than having a more recent host language). Is there anything in python 3 that would make it easier/harder for pypy? Thanks, Martin

2 1

Re: [pypy-dev] RinohType and PyPy2
by Maciej Fijalkowski 02 Mar '14

02 Mar '14

the first obvious thing that jumps at me is your casual use of sys._getframe - the JIT aborts in this case and proceeds to the interpreter (so you pay the price for JITting, while you also pay the prace for not having compiled assembler). That probably does not explain everything, but please don't use sys._getframe in production code if you want the JIT to be fast. On Sun, Mar 2, 2014 at 12:34 AM, Brecht Machiels <brecht(a)mos6581.org> wrote: > Hello, > > I've managed to backport RinohType to Python 2 (took me only a couple of hours thankfully). > > Results on my Celeron T3000 (Arch Linux x86_64): > CPython 3.3.4 14 s > PyPy3 2.1.0-beta1 61 s > CPython 2.7.6 15 s > PyPy 2.2.1 35 s > > If you want to give it a try (no external dependencies): > > git clone --branch pypy2 https://github.com/brechtm/rinohtype.git > cd rinohtype/examples/rfic2009 > rm -rf template.ptc; PYTHONPATH=../.. pypy template.py > > > While PyPy2 performs better than PyPy3, it's still much slower than CPython. Is RinohType hitting a weak spot in PyPy? Any hints on what I can do to improve performance? > > Best regards, > Brecht > > > _______________________________________________ > pypy-dev mailing list > pypy-dev(a)python.org > https://mail.python.org/mailman/listinfo/pypy-dev

2 1

RinohType and PyPy2
by Brecht Machiels 01 Mar '14

01 Mar '14

Hello, I've managed to backport RinohType to Python 2 (took me only a couple of hours thankfully). Results on my Celeron T3000 (Arch Linux x86_64): CPython 3.3.4 14 s PyPy3 2.1.0-beta1 61 s CPython 2.7.6 15 s PyPy 2.2.1 35 s If you want to give it a try (no external dependencies): git clone --branch pypy2 https://github.com/brechtm/rinohtype.git cd rinohtype/examples/rfic2009 rm -rf template.ptc; PYTHONPATH=../.. pypy template.py While PyPy2 performs better than PyPy3, it's still much slower than CPython. Is RinohType hitting a weak spot in PyPy? Any hints on what I can do to improve performance? Best regards, Brecht

1 0