Mailman 3 December 2013 - pypy-issue

[issue821] __debug__ is always True
by dag 23 Apr '14

23 Apr '14

New submission from dag <dag.odenhall(a)gmail.com>: Python 2.7.1 (b590cf6de419, Apr 30 2011, 02:00:34) [PyPy 1.5.0-alpha0 with GCC 4.4.3] on linux2 >>>> sys.flags.optimize, __debug__ (1, True) ---------- messages: 2909 nosy: dag, pypy-issue priority: bug release: 1.5 status: unread title: __debug__ is always True ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue821> ________________________________________

3 3

[issue832] Linux 3.0 kernel fallout
by David Edelsohn 23 Apr '14

23 Apr '14

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. 23 Apr '14

23 Apr '14

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 23 Apr '14

23 Apr '14

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 23 Apr '14

23 Apr '14

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 23 Apr '14

23 Apr '14

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 23 Apr '14

23 Apr '14

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 23 Apr '14

23 Apr '14

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 23 Apr '14

23 Apr '14

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 23 Apr '14

23 Apr '14

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