PyPy's Speed Center | Hacker News Reader

PyPy's Speed Center

speed.pypy.org

33 pointspykello17 comments

Given that this is in the news - the Python Software Foundation issued a grant to rewrite this software. While it's kind of good looking, the code is a mess and the original maintainer no longer available to help.

The goal is to have a kick-ass speed.

The chart doesn't seem to work properly in Chrome 26.0.1410.65 on OSX 10.6.8.

See http://jean-francois.im/temp/pypy-chart.png

that's really odd, you should maybe report to the JS lib authors?

I wonder if CPython will have JIT in the future

The question has been asked numerous times on various PyCons. And all the time Guido says that python is "fast enough" and doesn't need all the complications that JIT will bring into the codebase. In the same vain he speaks of GIL as something that is good enough and need not be removed.

For me both of the points sound like a denial and I'm extremely happy that there is a PyPy team who cares about performance and concurrency. The core python team is working on minor tweaks and small-ish features in 3.x which can't hold a candle to solid 2-3x performance increase, built-in support for stackless/greenlets, extremely fast built-in subset of numpy and prospects of running your code truly concurrently with stm.

IIRC, on of his reasons was that CPython works on a large set of architectures and OSes and it's impossible to write a JIT that works on all of them. JITs usually support only the most popular architectures(x86 and x86_64) and CPython wants to remain as architecture-agnostic as possible.

That's a bullshit argument and I don't think it was raised. You can always run JIT on a subset of architectures (ARM, x86, x86_64, PPC and MIPS really cover a lot) and run interpreter on others.

The argument was always "easier to maintain", but that said, unladen swallow was agreed to be merged into cpython, had it met it's goals.

> In the same vain he speaks of GIL as something that is good enough and need not be removed.

If you want to remove the GIL and come up with a way to make the thousands of 3rd-party modules still work, please do it. Beazley has investigated it, but if you think you can do better, please do it.

I'd rather have true threading power than thousands of 3rd party modules.

The modules can be re-written. By removing the GIL, we are giving a definite power boost to the language(applies to ruby too)

The extremely widespread use of CPython over PyPy suggests that most users feel differently.

Personally, if I had to go without 3rd party modules like numpy and pandas for any length of time, I might just switch to another language.

Most people seem to flock to the reference implementation of a language rather than alternatives. Which is why most people use CRuby even though JRuby is faster.

Guido should just take it like a man and accept a pull request to merge PyPy's JIT interpreter into CPython.

backward compatibility is not an issue. Otherwise why there are 3.x branch. This is just a lame excuse.

The 3.x branch still has a GIL, so those modules can still be compiled to work with python 3. If you think it is a lame excuse, you obviously haven't looked into the details and you don't understand the problem.

No reason why it would: Pypy exists.

How about memory usage? For what I do, that's considerably more important than CPU.

Memory usage is considerably down, in most cases as well (up in some, however)

The problem with memory usage is lack of benchmarks. For most of the benchmarks that are on the page it'll be only the interpreter size. We're working on a solution (and on memory usage) though.

Reply on news.ycombinator.com