So if I want to start using this. Do I just make a change at the environment level in virtualenv? And then all of my Python code will run faster?
PyPy: A Faster Python Implementation
21–25 of 25 posts
Re: PyPy: A Faster Python Implementation
#22Earlier quoted context omitted.
Are you sure? I did a cross-comparison recently and found LuaJIT still to be factor 1.3 to 1.5 faster than V8 in geometric mean (I used the Node.js implementation on the CLBG).
V8 8.0 is consistently faster than LuaJIT 2.1 on my machine even on heavily numeric benchmarks like Fannkuch or n-body. Anything more realistic involving actual object access, not even allocation, and V8 wins by large margins. time luajit-2.1.0-beta3 nbody.lua 50000000 real 0m8.437s time node nbody.js 50000000 real 0m5.065s
I assume you would get another result running all CLBG algorithms and comparing the geometric means. I also run benchmarks including (hashed) table/field access and was virtually as fast as the same program when compiled natively, see https://github.com/rochus-keller/Oberon/blob/master/testcase.... Of course there are parts where LuaJIT 2.0 is slower than native, but there are also some opposite cases.
Re: PyPy: A Faster Python Implementation
#23So if I want to start using this. Do I just make a change at the environment level in virtualenv? And then all of my Python code will run faster?
More or less. It really depends on what your code does and how frequently in calls into C modules such as Numpy. The Python side is JIT-able while the C side is not. PyPy3 currently implements Python 3.6.9 so you'll be missing out on any 3.7+ features (e.g., built-in dataclasses but a backport is available from PyPI).
Re: PyPy: A Faster Python Implementation
#24Earlier quoted context omitted.
Lots of discussion about obstacles to speeding up python in older threads, e.g. https://news.ycombinator.com/item?id=12025309
Thanks for the link. Had a quick look at the top rated comment, but "Python spends almost all of its time in the C runtime - This means that it doesn't really matter how quickly you execute the 'Python' part of Python" is already wrong. CPython is an interpreter, and this interpreter is implemented in C. You cannot argument that due to the fact that the runtime spends most of its time in C functions it makes no sense…
Over in #guile on freenode we just hit a bump where string-for-each on a string was a lot slower than (for-each proc (string->list lst)) due to a costly jump into C from the jitted code. Rewriting string-for-each in scheme solved the problem.
I don't know what I wanted to say with that, but I know pypy has spent a lot of time rewriting some core libraries in python/Rpython. I thought it was to make pypy more hackable, but maybe it has some jit benefits as well.
Re: PyPy: A Faster Python Implementation
#25pypy is great. what makes me sad is "they just stay behind cpython 1 or 2 versions"..
1-2 versions minor versions is pretty great. Most Linux distros that are deployed are the same!
PyPy claims to be compatible with CPython 3.6.9 (https://www.pypy.org/compat.html). CPython 3.7 is currently the most common Python version. The project I work on since last year depends on features introduced in CPython 3.7. The migration to CPython 3.8 in already underway on many Linux distros (Fedora is already on it). So PyPy is unfortunately too far behind.