5 ms·
These are fantastic news. Right now, PyPy is probable the biggest reason why many users don't migrate to Python 3 yet. Python 3 comes with a lot of very nice la
by ceronman 10y ago
These are fantastic news. Right now, PyPy is probable the biggest reason why many users don't migrate to Python 3 yet. Python 3 comes with a lot of very nice language features, but even when CPython 3 is already faster than 2.x in most cases, these speed increments are very small compared with the speedups of PyPy, which in my experience brings Python's speed to NodeJS level. I'm looking forward for their first release!
- radarsat1 10y ago> Right now, PyPy is probable the biggest reason why many users don't migrate to Python 3 yet. Does PyPy have that many users?
- pinaraf 10y agoWell, it weights in favor of Python 2, and considering that until recently the incencitives for Python 3 were still light... It's not really about having users, but having the possibility of switching from CPython to PyPy if you face performance issues.
- brianwawok 10y agoDoesn't seem that way to me. For actual real world apps with a lot of IO, your PyPy benefit is kinda small. For actual number crunching, I guess. Which is the whole scientific side of Python. Python is weird that it is 50% webapp hipsters ala Ruby, and 50% scientists in lab coats sitting in the lab crunching.
- rjeli 10y agoWell, PyPy does not actually help much with raw number crunching -- a scientist will use numpy for native matrix math, or numba to JIT a tight loop that can't be writted in numpy easily. PyPy really helps in the in-between cases: a few weeks ago I had to write a script to pull a few million rows from a database, process them nontrivially, and dump them to a file. What do I use here? CPython and Ruby will take days. Perl will probably take days, unless I am just doing text processing which perl is optimized for. I can write C or C++, and have the headache of debugging memory errors in a script that will only run once. Or, I can write PyPy and have immensely convenient syntax that will run reasonably quickly (Luajit also occupies this space for me).
- brianwawok 10y agoWell if this task is trivial to parallelize.. I would spin up 100 GCE machines for 1 penny each per hour after today's price drop (combined total of $1 per hour for 100 CPUs of action).. and pull those few million files and dump to a cloud drive in 1 hour flat. It's a tricky sweet spot PyPy has. Certain tasks that need CPU power but not too much CPU power and you want to spend time to make it run in parallel but not too much time to make it run across many machines. (By no means am I a PyPy or CPython expert. Just toyed with them and want to understand the bounds...)
- zardeh 10y agoBut now you have to manage that deployment which is also nontrivial.
- 10y ago
- StavrosK 10y ago> brings Python's speed to NodeJS level Does anyone have a benchmark? I hear this claim a lot, but I haven't seen NodeJS being that much faster.
- eeZi 10y agoNodeJS/V8 is faster than CPython for obvious reasons - V8 is JIT compiled while CPython is not. PyPy closes the gap.
- john_reel 10y agoLuaJIT made the news for having an interpreter that beat V8’s JIT a while ago. There are a lot of traits about languages and their implementations that makes looking at their compiler features a poor way of determining speed.
- mutagen 10y agoThe Techempower benchmarks show them each having their strengths, with 3 'wins' apiece: https://www.techempower.com/benchmarks/#section=data-r12&hw=peak&test=plaintext&l=1s0 https://www.techempower.com/benchmarks/#section=data-r12&hw=... The usual Techempower caveats apply: I have no idea about the implementations or any possible constraints on these, YMMV.
- StavrosK 10y agoThank you, that seems useful. I must be reading it wrong, though, because I see wsgi completing three times more responses than node.js, which seems wrong. I also can't find the "three wins each" that you reference. EDIT: Ah, I just noticed the different benchmark tabs at the top, thanks.
- zzleeper 10y agoSimilarly, Python 3.5 is (for me and probably others) the biggest reason for not using PyPy
- eeZi 10y agoAgreed. Looking forward to the 3.5 port.
- zyngaro 10y agoYou mean you don't use 3.5 be cause pypy does not support it.
- techdragon 10y agoNo, it seems like they are in the same position as myself. They (and myself) are not using PyPy because PyPy does not support Python 3.5
- michwill 10y agoI wonder if uvloop will work with such pypy. The speed would be awesome!
- brettcannon 10y agoIt's a possibility. uvloop is written in Cython so it will depend on whether PyPy3 supports what uvloop uses through Cython: http://docs.cython.org/en/latest/src/userguide/pypy.html http://docs.cython.org/en/latest/src/userguide/pypy.html
- 1st1 10y agoWe'll find a way. Worst case it's possible to rewrite it using cffi.
- rantanplan 10y ago> Right now, PyPy is probable the biggest reason why many users don't migrate to Python 3 yet I've met hundreds of pythonistas, in all sorts of different places. A lot of them wanted to migrate to Python 3.X not a single one told me that PyPy was a reason.
- epidemian 10y agoI fall in that camp too. I worked on a project where i really wanted to migrate to Python 3, mostly to have a saner Unicode story, but couldn't do it because it was deployed on Google App Engine :(
- sciurus 10y agoYou may already know, but you can use 3.4 if you switch from the "Standard Environment" to the "Flexible Environment". https://cloud.google.com/appengine/docs/flexible/ https://cloud.google.com/appengine/docs/flexible/
- epidemian 10y agoYep. Already tried that, but i found too many disadvantages on the "flexible" environment (still in beta, bad documentation, much slower deploys, minimum of one instance always running, etc) that i preferred to stay out of that for the time being.