10 comments

[ 5.0 ms ] story [ 37.3 ms ] thread
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.

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.
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.
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.

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.
in either case he's not accounting for the time the JIT (if he were actually using it) would need to warm up.

  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
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!)

I for one hope the best implementation gets included, not the one that has the most strings to pull.
(comment deleted)