Mailman 3 August 2014 - pypy-dev

use as benchmark pypy vs python if you please
by Dima Tisnek Sept. 13, 2015

Sept. 13, 2015

Attached is n-queens solver (pardon my naive algorithm), it runs: python 2.7.6: 17s pypy 2.4.0 alpha: 23s same nojit: 32s I've tried similar-looking algorithm for another problem before, and has similar results -- somehow pypy was slower. feel free to investigate / tweak or even use on speed.pypy.org

4 4

pypy 2.3.1 json encoding performnce is Extremely slow (30x slower ).
by Phyo Arkar Sept. 2, 2014

Sept. 2, 2014

$ pypy benchmark.py Array with 256 doubles: json encode : 5044.67291 calls/sec json decode : 19591.44018 calls/sec Array with 256 utf-8 strings: json decode UTF : 71.03748 calls/sec json decode UTF : 482.03748 calls/sec $ /usr/bin/python benchmark.py Array with 256 doubles: json encode : 4292.39818 calls/sec json decode : 15089.87792 calls/sec Array with 256 utf-8 strings: json encode UTF : 2062.16175 calls/sec json decode UTF : 479.04892 calls/sec Test using ultra json: $ /usr/bin/python ujson/test/benchmark.py Array with 256 doubles: ujson encode : 4386.51907 calls/sec simplejson encode : 4269.30241 calls/sec yajl encode : 4268.15286 calls/sec ujson decode : 23814.23743 calls/sec simplejson decode : 15375.76992 calls/sec yajl decode : 15388.19165 calls/sec Array with 256 utf-8 strings: ujson encode : 4114.12586 calls/sec simplejson encode : 1965.17111 calls/sec yajl encode : 1964.98007 calls/sec ujson decode : 1237.99751 calls/sec simplejson decode : 440.96787 calls/sec yajl decode : 440.53785 calls/sec Ofcoz it is not fair comparing against Ultra json but there is no real performance increase vs vanilla python's json

3 10

2.4 release process has begun
by Matti Picus Aug. 30, 2014

Aug. 30, 2014

1 0

Re: [pypy-dev] Adding a feature to re
by Laura Creighton Aug. 28, 2014

Aug. 28, 2014

In a message of Mon, 25 Aug 2014 03:20:55 -0400, Mike Kaplinskiy writes: >Hey folks, > >One of the projects I'm working on in CPython is becoming a little CPU >bound and I was hoping to use pypy. One problem though - one of the pieces >uses the regex library (which claims to be CPython's re-next). Running >regex through cpyext works, but is deadly slow. > >>From reading the docs it seems like I have a few options: > - rewrite all of regex in Python - seems like a bad idea > - rewrite regex to be non-python specific & use cppyy or cffi to interface >with it. I actually looked into this & unfortunately the CPython API seems >quite deep in there. > - get rid of the dependency somehow. What I'm missing are named lists >(basically "L<a>", a=["1","2"] will match 1 or 2). Unfortunately creating >one really long re string is out of the question - I have not seen >compile() finish with that approach. Writing a custom DFA could be on the >table, but I was hoping to avoid that error prone step. > - somehow factor out the part using regex and keep using CPython for it. > - add the missing functionality to pypy's re. This seems like the path of >least resistance. > >I've started looking into the sre module and it looks like quite a few bits >(parsing & compiling to byte code mostly) are reused from CPython. I would >have to change some of those bits. My question is then - is there any hope >of getting these changes upstream then? Do stdlib pieces have a "no touch" >policy? > >Thanks, >Mike. Do you know about https://pypi.python.org/pypi/regex If I were you, I would try to get the behaviour you want put into the new replacement version -- which would, of course, be easiest if you contributed the code. Then we can see about having pypy do the same ... Laura

3 2

Pidigits performance without FFI
by Wilfred Hughes Aug. 25, 2014

Aug. 25, 2014

Hi folks I've been looking at the pidigits benchmark from the Computer Language Benchmarks, but measuring performance without FFI (so native Python numbers instead of GMP). You can see my results here: https://github.com/Wilfred/the_end_times#preliminary-results I'm seeing better performance for CPython than pypy3 on simple arithmetic code. Is this to be expected? Could I make pypy3 perform better? Wilfred

2 1

Adding a feature to re
by Mike Kaplinskiy Aug. 25, 2014

Aug. 25, 2014

Hey folks, One of the projects I'm working on in CPython is becoming a little CPU bound and I was hoping to use pypy. One problem though - one of the pieces uses the regex library (which claims to be CPython's re-next). Running regex through cpyext works, but is deadly slow. >From reading the docs it seems like I have a few options: - rewrite all of regex in Python - seems like a bad idea - rewrite regex to be non-python specific & use cppyy or cffi to interface with it. I actually looked into this & unfortunately the CPython API seems quite deep in there. - get rid of the dependency somehow. What I'm missing are named lists (basically "L<a>", a=["1","2"] will match 1 or 2). Unfortunately creating one really long re string is out of the question - I have not seen compile() finish with that approach. Writing a custom DFA could be on the table, but I was hoping to avoid that error prone step. - somehow factor out the part using regex and keep using CPython for it. - add the missing functionality to pypy's re. This seems like the path of least resistance. I've started looking into the sre module and it looks like quite a few bits (parsing & compiling to byte code mostly) are reused from CPython. I would have to change some of those bits. My question is then - is there any hope of getting these changes upstream then? Do stdlib pieces have a "no touch" policy? Thanks, Mike.

1 0

Fwd: For py3k...
by Martin Matusiak Aug. 24, 2014

Aug. 24, 2014

Hi, So just to get a quick sanity check before I start. We are missing lzma in py3.3 (or to be more precise we have the beginnings of the module, but it's not passing any tests yet). Philip hinted to me recently that it would make sense to integrate lzmaffi. I would like to work on that, but I will probably get stuck a few times, so I'm planning to do some writeups on my blog as I go along (both for note taking and debugging). Since it's an external project I was planning to follow the same procedure that we use for stdlib, which is described in stdlib-upgrade.txt. So start out with vendor/lzmaffi, then branch off to py3.3-lzmaffi for integration work, finally merge into py3.3. Does that seem like a good approach? Martin 2014-07-23 19:20 GMT+02:00 Peter Cock <p.j.a.cock(a)googlemail.com>: > Thanks - that will be a useful companion to my backport > for using lzma on C Python 2.6, 2.7 and early Python 3 :) > https://pypi.python.org/pypi/backports.lzma > > Peter > > On Wed, Jul 23, 2014 at 5:14 PM, Armin Rigo <arigo(a)tunes.org> wrote: >> Hi all, >> >> A module mentioned today in a EuroPython lightning talk: "lzma" >> reimplemented in cffi (compatible with the one from Python 3.3's >> stdlib). >> >> https://pypi.python.org/pypi/lzmaffi >> >> >> A bientôt, >> >> Armin. >> _______________________________________________ >> pypy-dev mailing list >> pypy-dev(a)python.org >> https://mail.python.org/mailman/listinfo/pypy-dev > _______________________________________________ > pypy-dev mailing list > pypy-dev(a)python.org > https://mail.python.org/mailman/listinfo/pypy-dev

2 1

AssertionError in rpython_jit_metainterp_resume.c
by Anton Gulenko Aug. 22, 2014

Aug. 22, 2014

Hello, I am working on the RSqueak VM (https://bitbucket.org/pypy/lang-smalltalk). Usually I debug assertion errors by executing the VM in interpreted mode. Recently I started getting an error where that doesn't work. See below for the only output on the console. I am working on Windows, so the VM is compiled with Visual Studio. The VM is translated using the pypy commit tagged "release-2.3.1". RPython traceback: File "rpython_jit_metainterp_compile.c", line 379, in ResumeGuardForcedDescr_handle_async_forcing File "rpython_jit_metainterp_resume.c", line 256, in force_from_resumedata File "rpython_jit_metainterp_virtualizable.c", line 426, in write_from_resume_data_partial File "rpython_jit_metainterp_resume.c", line 768, in ResumeDataDirectReader_decode_ref Fatal RPython error: AssertionError Since this seems to be related to virtualizable objects: during translation we get 2 warnings that the "fresh_virtualizable" hints are ignored (there are 2 places where virtualizable frame objects are created. Also, we have one virtualizable list[*] field in our Context class, which should never be resized. I applied the make_sure_not_resized hint on it, but maybe I'm using it wrong... I'm just calling make_sure_not_resized once, after setting the list field. Any ideas? Thanks in advance! Best, Anton

2 7

Mini-sprint August 25-27 in Switzerland
by Armin Rigo Aug. 14, 2014

Aug. 14, 2014

Hi all, We're running a 3-days mini-sprint the 25-27 of August at the University of Neuchatel, Switzerland, research group of Pascal Felber. This is not a general PyPy sprint, but one on the topic of STM specifically. Nevertheless, in case there is someone nearby who listens to this mailing list and who would like to show up (from one day to the full 3 days), he is welcome to. More details: the mini-sprint is about anything related to PyPy-STM, but more precisely, now would be a good time to try to push the idea forward, now that we have an almost reasonable core working (however rough). This would involve in general the question: what does it mean for the user? Should we scrap atomic blocks and instead focus on lock elision (as a more backward-compatible idea with nicer fallbacks in case we try to do I/O in the atomic block)? We definitely should make dictionaries more aware of multithreading, but is that enough to avoid most "unexpected" conflicts? Can we try to adapt a larger single-threaded framework (my favourite is Twisted) to run on multiple threads transparently for the user's applications? A bientôt, Armin.

1 0

Re: [pypy-dev] trouble compiling p4python api with pypy3
by Armin Rigo Aug. 11, 2014

Aug. 11, 2014

Hi Russ, On 10 August 2014 19:39, Russ Tremain <russt(a)releasetools.org> wrote: > Would it be better to customize the api to comply with the "native" pypy interface? The "native" pypy interface is cffi (which also works on CPython, btw). It would definitely give better stability and performance on PyPy. It's more than just adapting some C code here and there, though. http://cffi.readthedocs.org/ Armin

2 1