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.
The first stable release of PyPy3
61–70 of 92 posts
Re: The first stable release of PyPy3
#62Earlier 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…
Re: The first stable release of PyPy3
#63Earlier 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…
Re: The first stable release of PyPy3
#64Re: The first stable release of PyPy3
#65Re: The first stable release of PyPy3
#66Re: The first stable release of PyPy3
#67Earlier 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.
Re: The first stable release of PyPy3
#68Earlier 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.
Re: The first stable release of PyPy3
#69Minor 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?
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
#70Earlier 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.