[pypy-dev] PyPy 1.7 - widening the sweet spot

[Blaine]

I've got a pure python and also equivalent C++ (with cython) cellular
automata engine that I use as benchmarks. Thought the group would be
interested in my results with the new pypy-1.7. The c++ engine is the
original file and I built a thin interface with cython. I ported this to
python and it is functionally equivalent. Most of the computation is simply
bit operations, shifting, and writing to a wrap-around buffer.
Interestingly, pypy chews through tens of millions of generations more
easily than the C++ due to some latent memory issues that are probably a
result of some error by me in coding. pypy doesn't seem to care, where the
C++ engine brings my laptop to a crawl (choppy mouse, low responsiveness,
etc) wth 10,000,000 generations.

1-dimensional cellular automata. Rule 30, 10,000 cells wide, 10,000
generations. This project is available on my github (print_ca.py is the
benchmark i'm using). https://github.com/booherbg/PyAutomata

*pypy-1.6 with pure python module*
[blaine at macbook:~/src/PyAutomata Tue Nov 22]
30$ time pypy-1.6 print_ca.py 30 10000 10000 --quiet --python
using pyautomata interface: PYTHON

real 0m13.812s
user 0m13.540s
sys 0m0.170s

*pypy-1.7 with pure python module (14% faster than pypy-1.6)*
[blaine at macbook:~/src/PyAutomata Tue Nov 22]
29$ time pypy-1.7 print_ca.py 30 10000 10000 --quiet --python
using pyautomata interface: PYTHON

real 0m11.952s
user 0m11.730s
sys 0m0.140s


*cpython with c++ interface - only ~2.5 times faster than pypy-1.7*
[blaine at macbook:~/src/PyAutomata Tue Nov 22]
31$ time python print_ca.py 30 10000 10000 --quiet
using pyautomata interface: C++

real 0m4.818s
user 0m4.680s
sys 0m0.060s

*cpython with pure python interface - abysmally slow, ~160x slower than
C++, ~64x slower than pypy-1.7*
[blaine at macbook:~/src/PyAutomata Tue Nov 22]
32$ time python print_ca.py 30 10000 10000 --quiet --python
using pyautomata interface: PYTHON

real 12m50.927s
user 12m48.380s
sys 0m0.510s


c++ build commands:
[blaine at macbook:~/src/PyAutomata Tue Nov 22]
36$ make
mkdir -p build/temp.linux-x86_64-2.6/
cython --cplus pyAutomata.pyx
# The following was generated based on setup.py; ython setup.py build_ext
--inplace
gcc -march=native -O2 -pthread -fno-strict-aliasing -fwrapv -Wall -fPIC -I.
-Iautomata-1.0.0/ -I/usr/include/python2.6 -c pyAutomata.cpp -o
build/temp.linux-x86_64-2.6//pyAutomata.o
gcc -march=native -O2 -pthread -fno-strict-aliasing -fwrapv -Wall -fPIC -I.
-Iautomata-1.0.0/ -I/usr/include/python2.6 -c automata-1.0.0//Automata.cpp
-o build/temp.linux-x86_64-2.6//automata-1.0.0//Automata.o
g++ -march=native -lm -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
build/temp.linux-x86_64-2.6//pyAutomata.o
build/temp.linux-x86_64-2.6//automata-1.0.0//Automata.o -lstdc++ -o
pyAutomata.so


Blaine


On Tue, Nov 22, 2011 at 9:42 AM, Phyo Arkar <phyo.arkarlwin at gmail.com>wrote:

> nice
>
>
> On Tue, Nov 22, 2011 at 7:01 PM, Bruno Gola <brunogola at gmail.com> wrote:
>
>> Hi,
>>
>> Just to let you know I just uploaded the new release to the official PPA,
>> so if you use Ubuntu you can install PyPy 1.7 using
>> https://launchpad.net/~pypy/+archive/ppa
>>
>> Tests and feedback are welcome :-)
>>
>> Thanks,
>> Bruno
>>
>> On Tue, Nov 22, 2011 at 7:36 AM, Phyo Arkar <phyo.arkarlwin at gmail.com>wrote:
>>
>>> I understand the complication of binary release.
>>>
>>> i did cross reference 1.0.0  and it works (starts) pypy fine,. But i am
>>> not sure what will happen if something that uses crypting modules.
>>>
>>> may be release both versions of openssl (damn , python should have have
>>> that openssl dependancy in standard modules :( )
>>>
>>>
>>> On Tue, Nov 22, 2011 at 3:40 PM, Armin Rigo <arigo at tunes.org> wrote:
>>>
>>>> Hi Phyo,
>>>>
>>>> On Tue, Nov 22, 2011 at 09:38, Phyo Arkar <phyo.arkarlwin at gmail.com>
>>>> wrote:
>>>> > in my Gentoo based Sabayon they are already gone. and i believe next
>>>> latest
>>>> > Ubuntu may use 1.0.0 too.
>>>>
>>>> The point is of course that doing binary releases on Linux is always a
>>>> bit of a problem, unless we ship everything as included static
>>>> libraries, which is a bit nonsensical IMHO for a project like PyPy.
>>>>
>>>> Moreover, if openssl 1.0.0 is binary compatible with openssl 0.9.8,
>>>> then I might rather put the blame on the openssl project for releasing
>>>> two binary compatible versions with a different (un-cross-linkable)
>>>> first number.  But I will not do so: I guess that they are not
>>>> supposed to be totally binary compatible, and there are subtle
>>>> differences.
>>>>
>>>> Is there anyone that can (1) make sure the differences don't matter,
>>>> possibly by looking at how the CPython source evolved; and (2) maybe
>>>> come up with a way to say "link against openssl either 0.9.8 or 1.0.0"
>>>> in the binary?
>>>>
>>>>
>>>> A bientôt,
>>>>
>>>> Armin.
>>>>
>>>
>>>
>>> _______________________________________________
>>> pypy-dev mailing list
>>> pypy-dev at python.org
>>> http://mail.python.org/mailman/listinfo/pypy-dev
>>>
>>>
>> _______________________________________________
>> pypy-dev mailing list
>> pypy-dev at python.org
>> http://mail.python.org/mailman/listinfo/pypy-dev
>>
>>
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20111122/ec43b4fe/attachment-0001.html>