4 ms·

Someone needs to tell them that an "unstable beta" should not be given a version number above 1.0... Still, this is pretty exciting news: A speedy, JIT Python

Someone needs to tell them that an "unstable beta" should not be given a version number above 1.0... Still, this is pretty exciting news: A speedy, JIT Python compiler written in Python. I look forward to seeing PyPy become the canonical Python compiler in a couple of years.

Estragon 17y ago
I wouldn't call it speedy: met% python -m timeit "sum(x**2 for x in xrange(10000))" 1000 loops, best of 3: 1.14 msec per loop met% ./bin/pypy -m timeit "sum(x**2 for x in xrange(10000))" 100 loops, best of 3: 5.18 msec per loop Almost a five-fold slowdown, in my hands.
- tetha 17y ago
  Of course, the slowness of a single artifical <50-character program completely demonstrates the slowness of a jit-compiler for a dynamic language, and clearly they should stop devleoping right now.
  - Estragon 17y ago
    Straw man. I was responding to the claim in the parent that it's speedy. Don't know what you mean by artificial; it was the first test I tried.
- pgbovine 17y ago
  is ./bin/pypy the version of pypy that's been compiled or simply the pure-python interpreted version (easy check is to view it in an editor)? if you're running the interpreted version, then that makes sense that it's 5x slower.
  - enki 17y ago
    in either case he's not accounting for the time the JIT (if he were actually using it) would need to warm up.
  - Estragon 17y ago
    met% file ./bin/pypy ./bin/pypy: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped
pgbovine 17y ago
I look forward to seeing PyPy become the canonical Python compiler in a couple of years. I think Unladen Swallow might be ahead of them on that one since they're much closer to getting integrated with Python 3.0 (and they're supported by Google, who also has Guido on their payroll!)
- algorias 17y ago
  I for one hope the best implementation gets included, not the one that has the most strings to pull.

Estragon 17y ago

I wouldn't call it speedy: met% python -m timeit "sum(x**2 for x in xrange(10000))" 1000 loops, best of 3: 1.14 msec per loop met% ./bin/pypy -m timeit "sum(x**2 for x in xrange(10000))" 100 loops, best of 3: 5.18 msec per loop Almost a five-fold slowdown, in my hands.

tetha 17y ago
Of course, the slowness of a single artifical <50-character program completely demonstrates the slowness of a jit-compiler for a dynamic language, and clearly they should stop devleoping right now.
- Estragon 17y ago
  Straw man. I was responding to the claim in the parent that it's speedy. Don't know what you mean by artificial; it was the first test I tried.
pgbovine 17y ago
is ./bin/pypy the version of pypy that's been compiled or simply the pure-python interpreted version (easy check is to view it in an editor)? if you're running the interpreted version, then that makes sense that it's 5x slower.
- enki 17y ago
  in either case he's not accounting for the time the JIT (if he were actually using it) would need to warm up.
- Estragon 17y ago
  met% file ./bin/pypy ./bin/pypy: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped

pgbovine 17y ago

I look forward to seeing PyPy become the canonical Python compiler in a couple of years. I think Unladen Swallow might be ahead of them on that one since they're much closer to getting integrated with Python 3.0 (and they're supported by Google, who also has Guido on their payroll!)

algorias 17y ago
I for one hope the best implementation gets included, not the one that has the most strings to pull.