Mailman 3 August 2013 - pypy-issue

[issue832] Linux 3.0 kernel fallout
by David Edelsohn April 23, 2014

April 23, 2014

New submission from David Edelsohn <dje.gcc(a)gmail.com>: PyPy follows CPython 2.7, which does not recognize the new 3.0 Linux kernel series. Code expects sys.platform == 'linux2' ---------- messages: 2966 nosy: edelsohn, pypy-issue priority: bug status: unread title: Linux 3.0 kernel fallout ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue832> ________________________________________

5 6

[issue733] bz2 decompression is very slow
by Jonas H. April 23, 2014

April 23, 2014

New submission from Jonas H. <jonas(a)lophus.org>: Compared to CPython 2.7, PyPy 1.5 (from the Arch Linux repositories) seems to be ~5 times slower on bz2 decompression. Using this script: from bz2 import BZ2File with BZ2File(sys.argv[1]) as f: while True: if not f.read(8*1024): break to decompress the PyPy lib-python/ directory (60M compressed) takes about 5 seconds on CPython and 20s on PyPy 1.5. ---------- messages: 2569 nosy: jonash, pypy-issue priority: bug release: 1.5 status: unread title: bz2 decompression is very slow ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue733> ________________________________________

5 10

[issue931] web site bugs
by Armin Rigo April 23, 2014

April 23, 2014

New submission from Armin Rigo <armin.rigo(a)gmail.com>: On the web site http://pypy.org: home page -> click "donate to py3k" -> click "read proposal" it ends up selecting "donate to numpy" again, which is confusing. Also the text "This donation will go towards supporting NumPy in PyPy Read proposal" would be more readable with a dot or a line break. ---------- messages: 3447 nosy: arigo, pypy-issue priority: bug status: unread title: web site bugs ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue931> ________________________________________

2 1

[issue888] json module in pypy is much more lower than cpython
by ayanamist April 23, 2014

April 23, 2014

New submission from ayanamist <ayanamist(a)gmail.com>: You can see more detail here: https://gist.github.com/1250244 I just use and modify the benchmark.py from ujson, running it in my virtual machine. File "environment" tells my machine. File "benchmark.py" is the one i modified from ujson File "result-pypy" and "result-python" are the results. It's much slower. I hope you guys can speed up. ---------- messages: 3215 nosy: ayanamist, pypy-issue priority: wish status: unread title: json module in pypy is much more lower than cpython ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue888> ________________________________________

3 3

[issue843] PyPy slower than CPython with puzzle problem
by Alex Krusz April 23, 2014

April 23, 2014

New submission from Alex Krusz <harfatum(a)gmail.com>: Input/Output: D:\Python>python athena_16.py 48 10 [2, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3] set([3318]) [[3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 2] ] 806844323190414 Total time was 6.473 seconds. D:\Python>pypy athena_16.py 48 10 [2, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3] set([3318]) [[3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 2] ] 806844323190414 Total time was 10.525 seconds. ============================ This code was written to satisfy the following problem: Your niece was given a set of blocks for her birthday, and she has decided to build a panel using 3”×1” and 4.5”×1" blocks. For structural integrity, the spaces between the blocks must not line up in adjacent rows. For example, the 13.5”×3” panel below is unacceptable, because some of the spaces between the blocks in the first two rows line up (as indicated by the dotted line). There are 2 ways in which to build a 7.5”×1” panel, 2 ways to build a 7.5”×2” panel, 4 ways to build a 12”×3” panel, and 7958 ways to build a 27”×5” panel. How many different ways are there for your niece to build a 48”×10” panel? The answer will fit in a 64-bit integer. Write a program to calculate the answer. The program should be non-interactive and run as a single-line command which takes two command-line arguments, width and height, in that order. Given any width between 3 and 48 that is a multiple of 0.5, inclusive, and any height that is an integer between 1 and 10, inclusive, your program should calculate the number of valid ways there are to build a wall of those dimensions. Your program’s output should simply be the solution as a number, with no line-breaks or white spaces. ---------- files: athena_16.py messages: 3005 nosy: Harfatum, pypy-issue priority: bug status: unread title: PyPy slower than CPython with puzzle problem ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue843> ________________________________________

6 9

[issue865] Struct.pack and unpack 3x and 6x slower than CPython
by Josh Ayers April 23, 2014

April 23, 2014

New submission from Josh Ayers <josh.ayers(a)gmail.com>: Using struct.pack and struct.unpack is significantly slower on PyPy 1.6 than on CPython 2.7.2 when packing a large list. This is under Windows 7. A summary of the timing results is shown below and the code used is attached. The attached code uses 4 byte integers. Floats show similar results. 4 MB 40 MB 80 MB pack unpack pack unpack pack unpack CPython 0.13 0.03 1.30 0.29 2.60 0.60 PyPy 0.43 0.20 3.90 1.77 8.03 3.59 Factor 3.3x 6.7x 3.0x 6.1x 3.1x 6.0x The benchmark code packs a large list, writes it to a file, then reads the file back in and unpacks it. I didn't include it in the table above, but the reading portion was also slower in PyPy. However, it wasn't as large of a difference as the struct packing and unpacking portion. ---------- messages: 3105 nosy: jayers2003, pypy-issue priority: feature status: unread title: Struct.pack and unpack 3x and 6x slower than CPython ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue865> ________________________________________

4 5

[issue837] Behavior Differs Between Interpreter and JIT
by Winston Ewert April 23, 2014

April 23, 2014

New submission from Winston Ewert <winstonewert(a)gmail.com>: The attached interpreter doesn't do the same thing when interpreted as with the jit. $ pypy strip.py (no output) $ pypy ../pypy/pypy/translate/goal/translate.py --opt=jit strip.py (...) $ ./strip-c Not found: 2 RPython traceback: File "jit_metainterp_blackhole.c", line 6526, in handler_inline_call_ir_r_1 File "implement.c", line 3468, in call_stub_6 File "implement.c", line 1596, in Frame_load Fatal RPython error: AssertionError Aborted It appears to have something to do with my use of virtualizables. ---------- messages: 2991 nosy: pypy-issue, winstonewert priority: bug status: unread title: Behavior Differs Between Interpreter and JIT ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue837> ________________________________________

3 3

[issue805] 64 bit 30% slower than 32bit pypy
by Fijal April 23, 2014

April 23, 2014

New submission from Fijal <fijall(a)gmail.com>: Attached example (regexes) ---------- messages: 2841 nosy: fijal, pypy-issue priority: bug status: unread title: 64 bit 30% slower than 32bit pypy ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue805> ________________________________________

2 1

[issue718] string.plit('\x00') takes 300% longer under pypy1.5 w/jit
by Robert Collins April 23, 2014

April 23, 2014

New submission from Robert Collins <robertc(a)robertcollins.net>: under cpython: 11:37 < lifeless> 3 0.000 0.000 0.280 0.093 journals.py:678(_tokens) under pypy(1.5, 64-bit build, your official download) 11:38 < lifeless> 3 0.000 0.000 1.161 0.387 journals.py:678(_tokens) _tokens is defined as def _tokens(): return content.split('\x00') content in the timed case is a 74MB bytestring consisting of \x00 separated fields; the fields are highly redundant - for example one in 5 in the case that produced this is 'add', another one in 5 is 'file', and the rest are 'dir', 'symlink' and relative paths, and floats (as ascii). There are 3331176 fields (len(content.split('\x00'))==3331176) ---------- effort: ??? messages: 2507 nosy: lifeless, pypy-issue priority: bug release: ??? status: unread title: string.plit('\x00') takes 300% longer under pypy1.5 w/jit _______________________________________________________ PyPy development tracker <pypy-dev-issue(a)codespeak.net> <https://codespeak.net/issue/pypy-dev/issue718> _______________________________________________________

3 2

[issue782] Order of calls changes performance
by Ismael April 23, 2014

April 23, 2014

New submission from Ismael <ismaelgfk(a)gmail.com>: In the following code, the order of calls alters the performance. First case: running calc first, then calc_arr second: ismael@chaos:~/Escritorio$ ~/pypy/bin/pypy slow.py Section time: 0.865699052811 -- Calc Section time: 0.757493019104 -- Calc_arr So, here, best time for calc_arr is 0.75s. It doesn't matter if I run it 10 times, it still about that fast. Now, running calc_arr first and calc second: ismael@chaos:~/Escritorio$ ~/pypy/bin/pypy slow.py Section time: 0.400774002075 -- Calc_arr Section time: 1.53682088852 -- Calc The method that took 0.7s now takes 0.4! And the one that took 0.8s now takes 1.5! For comparison, PyPy latest (45351) is even worse: ismael@chaos:~/Escritorio$ ~/pypy/pypylatest/pypy-c-jit-45351-2630c86662b4-linux64/bin/pypy slow.py Section time: 0.940190792084 -- Calc Section time: 0.925091981888 -- Calc_arr ismael@chaos:~/Escritorio$ ~/pypy/pypylatest/pypy-c-jit-45351-2630c86662b4-linux64/bin/pypy slow.py Section time: 0.418694019318 -- Calc_arr Section time: 1.73908495903 -- Calc Code modified from http://technicaldiscovery.blogspot.com/2011/07/speeding-up-python-again.html class Timer(object): def __enter__(self): self.start = time.time() def __exit__(self, exc_type, exc_val, tb): print "Section time: ", time.time() - self.start import array import time dx = 0.1 dy = 0.1 dx2 = dx*dx dy2 = dy*dy def py_update(u,nx,ny): for i in xrange(1,nx-1): for j in xrange(1, ny-1): u[i][j] = ((u[i+1][j] + u[i-1][j]) * dy2 + (u[i][j+1] + u[i][j-1]) * dx2) / (2*(dx2+dy2)) def calc(N, Niter=100): u = [[0.0]*N for i in xrange(N)] for i in xrange(N): u[0][i] = 1.0 for i in range(Niter): py_update(u,N,N) return u def calc_arr(N, Niter=100): u = [array.array("d", [0.0])*N for i in xrange(N)] for i in xrange(N): u[0][i] = 1.0 for i in range(Niter): py_update(u,N,N) return u #Compare this: with Timer(): u = calc_arr(150,1000) with Timer(): u = calc(150,1000) #To this (comment the previous section): with Timer(): u = calc(150,1000) with Timer(): u = calc_arr(150,1000) ---------- messages: 2741 nosy: Ismael, pypy-issue priority: bug release: 1.5 status: unread title: Order of calls changes performance ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue782> ________________________________________

4 5