Live data from Hacker News

The first stable release of PyPy3

morepypy.blogspot.com

61–70 of 92 posts

Re: The first stable release of PyPy3

#61

Earlier quoted context omitted.

PyPy seems to be 7x faster!

On a silly piece of code that nobody would ever have any use for. I have tried PyPy for "real" data and numerical tasks from time to time, and never have I noticed any sort of speedup. Usually it's slower than CPython. Perhaps this latest version will be different, who knows.

You do remember that it's a jit and the first run is not fast? You have to let it run for a while to generate fast code and only benchmark after that.

Re: The first stable release of PyPy3

#62

Earlier quoted context omitted.

On a silly piece of code that nobody would ever have any use for. I have tried PyPy for "real" data and numerical tasks from time to time, and never have I noticed any sort of speedup. Usually it's slower than CPython. Perhaps this latest version will be different, who knows.

I'm using it in production, and speedups tend to be on the order of 4-5x for my app (the compute-intensive part involves hierarchical agglomerative clustering of documents by text similarity, so it's data/numbers-heavy). Obviously it'll depend on your individual application (and non-CPU-bound tasks won't benefit much), but we switched to PyPy because it showed major improvements in profiling of our app on production…

It's not like everyone's just imagining that it's slower for many work loads either.

Re: The first stable release of PyPy3

#63
post #31
post #6

Earlier quoted context omitted.

> I wish the community would just switch entirely to pypy. What purpose would that serve? > Being able to just slightly performance sensitive code in python is a huge win. I think you slightly this phrase, but aside from that pypy does not work for everybody and everything (e.g. at best it's no slower for sphinx, it really doesn't like the way docutils works). It's not like pypy's a magic wand.

> What purpose would that serve? If PyPy became the official/canonical implementation, PyPy would receive more attention and third-party library compatibility would be a requirement. Complaints about Python's slowness would be somewhat less relevant, and Python might see wider adoption. The RPython toolchain would receive more attention and that could be useful to other languages. There are plenty of reasons, but PyP…

I agree entirely. What's kind of a pity is that until NumPy is ported over, all of the scientific stack is basically unusable on PyPy - and right now, there are several incredibly good NumPy specific JITs (numexpr, numba, parakeet).

Re: The first stable release of PyPy3

#67
post #14

Earlier quoted context omitted.

Maybe moving libraries & code to Python 3 should be the priority.

Convincing distros to package it as the default "python" should be the priority. Until that happens, Python 3 will see limited adoption. The path of least resistance will always have the most traffic.

It's a chicken and egg problem. So long as most Python libraries run on Python 2 but not Python 3, distros are going to package Python 2.

Re: The first stable release of PyPy3

#68
post #14

Earlier quoted context omitted.

Maybe moving libraries & code to Python 3 should be the priority.

Convincing distros to package it as the default "python" should be the priority. Until that happens, Python 3 will see limited adoption. The path of least resistance will always have the most traffic.

Ubuntu seems to have that as a near-term goal: https://wiki.ubuntu.com/Python/3

Re: The first stable release of PyPy3

#69

Minor note: the openbsd support (at least for 2.x) is amd64 only. Building for i386 at some point requires running a bootstrap process that doesn't fit in memory.

> Building for i386 at some point requires running a bootstrap process that doesn't fit in memory. Seriously, it takes more than 4gigs to build PyPy? Is that also necessary for other platforms besides OpenBSD?

http://stackoverflow.com/questions/8452396/does-pypy-transla...

Pypy is written in RPython, a subset of the python language. When it's 'compiled', the pypy RPython code runs in cpython or pypy, to re-compile the pypy source into C code, to generate a binary. Lots of tuning and such occurs at the same time, so the JIT runs well on the target machine. This is why it takes a long while, and lots of memory.

The build also prints a fractal while compiling. http://pypy.readthedocs.org/en/latest/faq.html#why-does-pypy...

Re: The first stable release of PyPy3

#70
post #14

Earlier quoted context omitted.

Maybe moving libraries & code to Python 3 should be the priority.

Convincing distros to package it as the default "python" should be the priority. Until that happens, Python 3 will see limited adoption. The path of least resistance will always have the most traffic.

The first step is to get everything python3 compatible, and have it use a hashbang or other mechanism to select the right interpreter. After this happens, the default interpreter has no real meaning: everything will use the right interpreter.
Post reply on HN