3 ms·

I thought the 25% number was Falcon vs. CPython, not PyPy vs. CPython. The paper suggests (though does not say directly) that PyPy is faster than Falcon, and t

I thought the 25% number was Falcon vs. CPython, not PyPy vs. CPython. The paper suggests (though does not say directly) that PyPy is faster than Falcon, and that the only benefit of Falcon is compatibility with existing C extensions.

ProblemFactory 11y ago
But compatibility with C extensions is a major selling point. 25% speedup for pure Python code is not that appealing in numerical analysis code, when you can use NumPy, or sprinkle a few typedefs into a critical function and compile with Cython for a 1000x speedup. If C extension compatibility is broken, then many Python programs will altogether still be slower, despite the pure python speedup.
- awinter-py 11y ago
  cython community can definitely use some love -- there's a ton of low-hanging fruit (unboxing arrays of extension classes, for example) they haven't gotten to because of time / funding constraints. Not an apples to apples comparison, but my guess is the state of the art of JIT is way ahead of what the cython compiler can detect; some of the JIT tricks will likely work in the cython static translation step.
  - awinter-py 11y ago
    And to be clear I love cython, it's very useful as-is -- there's a large community of people for whom C & python expertise have gone hand in hand for years, and cython is the tool they end up using to max productivity and minimize surprises.
Animats 11y ago
That's about right. That's about where Unladen Swallow maxed out. To get beyond that point, you have to do more global analysis and JIT compilation and recompilation, as PyPy does. Every Python symbol reference requires a dictionary lookup. Every function call and operator requires that the type of the left hand side be examined for dispatching purposes. More than 99% of the time, the symbol and type will be the same as last time, and it's a huge win to assume that it will be and compile code for that case. You still have to be prepared for the times when it isn't, and have a backup system. That's basically what PyPy does. More stuff is mutable in Python than really needs to be mutable.
- rcarmo 11y ago
  That is true. I've been fooling around with Hy (hylang.org) for a fairly long time because it's nicer than Clojure for doing glue, and that has made me wonder how fast some things would go if Python had native immutable data types.
- gsnedders 11y ago
  > That's about right. That's about where Unladen Swallow maxed out. To get beyond that point, you have to do more global analysis and JIT compilation and recompilation, as PyPy does. Unladen Swallow did JIT compilation and recompilation, despite not doing better.
piquadrat 11y ago
Rereading my comment, it can easily be misunderstood. Sorry about that. The 25% average speedup they cite is indeed relative to CPython. Thanks for clarifying!
awinter-py 11y ago
I think the newest version of RPython has better FFI; they've been blogging about lxml compatibility for a few months.

ProblemFactory 11y ago

But compatibility with C extensions is a major selling point. 25% speedup for pure Python code is not that appealing in numerical analysis code, when you can use NumPy, or sprinkle a few typedefs into a critical function and compile with Cython for a 1000x speedup. If C extension compatibility is broken, then many Python programs will altogether still be slower, despite the pure python speedup.

awinter-py 11y ago
cython community can definitely use some love -- there's a ton of low-hanging fruit (unboxing arrays of extension classes, for example) they haven't gotten to because of time / funding constraints. Not an apples to apples comparison, but my guess is the state of the art of JIT is way ahead of what the cython compiler can detect; some of the JIT tricks will likely work in the cython static translation step.
- awinter-py 11y ago
  And to be clear I love cython, it's very useful as-is -- there's a large community of people for whom C & python expertise have gone hand in hand for years, and cython is the tool they end up using to max productivity and minimize surprises.

Animats 11y ago

That's about right. That's about where Unladen Swallow maxed out. To get beyond that point, you have to do more global analysis and JIT compilation and recompilation, as PyPy does. Every Python symbol reference requires a dictionary lookup. Every function call and operator requires that the type of the left hand side be examined for dispatching purposes. More than 99% of the time, the symbol and type will be the same as last time, and it's a huge win to assume that it will be and compile code for that case. You still have to be prepared for the times when it isn't, and have a backup system. That's basically what PyPy does. More stuff is mutable in Python than really needs to be mutable.

rcarmo 11y ago
That is true. I've been fooling around with Hy (hylang.org) for a fairly long time because it's nicer than Clojure for doing glue, and that has made me wonder how fast some things would go if Python had native immutable data types.
gsnedders 11y ago
> That's about right. That's about where Unladen Swallow maxed out. To get beyond that point, you have to do more global analysis and JIT compilation and recompilation, as PyPy does. Unladen Swallow did JIT compilation and recompilation, despite not doing better.

piquadrat 11y ago

Rereading my comment, it can easily be misunderstood. Sorry about that. The 25% average speedup they cite is indeed relative to CPython. Thanks for clarifying!

awinter-py 11y ago

I think the newest version of RPython has better FFI; they've been blogging about lxml compatibility for a few months.