PyPy v5.8 released
morepypy.blogspot.com
PyPy v5.8 released
1–10 of 74 posts
Re: PyPy v5.8 released
#2I guess the next release is the one that should support Python 3. At least as a non-beta feature.
Re: PyPy v5.8 released
#3PyPy is great -- while I still use CPython for our more complex webapp and associated tools that have heavy dependencies on C-extensions; I increasingly use PyPy for the more mundane cpu/data heavy lifting I do. It's typical to get 2X the performance (comparable to some compiled languages) and still use much of our utility code, configs, etc.
Re: PyPy v5.8 released
#4Awesome news, congrats to the team :)
On an unrelated note, I wish Google gave them money to make it work with Tensorflow.
Re: PyPy v5.8 released
#5PyPy is great -- while I still use CPython for our more complex webapp and associated tools that have heavy dependencies on C-extensions; I increasingly use PyPy for the more mundane cpu/data heavy lifting I do. It's typical to get 2X the performance (comparable to some compiled languages) and still use much of our utility code, configs, etc.
>comparable to some compiled languages
Given that python programs usually run an order of magnitude slower than compiled languages even a 2x performance increase doesn't put it in the "comparable" range from my experience. Not bashing python - I use it regularly - but for computational stuff it's a hog unless you're just passing stuff to C libs - like I have a resource build pipeline that does some blender 3D model transformations - code is written in python and takes forever - equivalent code in C++ would take roughly 1/100 of the time and performance would be irrelevant but atm. we're seriously considering rewriting parts in C++ to reduce build times.
Re: PyPy v5.8 released
#6PyPy is great -- while I still use CPython for our more complex webapp and associated tools that have heavy dependencies on C-extensions; I increasingly use PyPy for the more mundane cpu/data heavy lifting I do. It's typical to get 2X the performance (comparable to some compiled languages) and still use much of our utility code, configs, etc.
>comparable to some compiled languages Given that python programs usually run an order of magnitude slower than compiled languages even a 2x performance increase doesn't put it in the "comparable" range from my experience. Not bashing python - I use it regularly - but for computational stuff it's a hog unless you're just passing stuff to C libs - like I have a resource build pipeline that does some blender 3D model t…
It all depends on the task -- if your program is calling into optimized C-extensions anyway, converting the whole thing into a compiled language of course offers less of a speedup.
Re: PyPy v5.8 released
#7Awesome work, congratulations on bringing Python forward.
Still wishing one day PyPy might become the canonical implementation.
Re: PyPy v5.8 released
#8PyPy is great -- while I still use CPython for our more complex webapp and associated tools that have heavy dependencies on C-extensions; I increasingly use PyPy for the more mundane cpu/data heavy lifting I do. It's typical to get 2X the performance (comparable to some compiled languages) and still use much of our utility code, configs, etc.
>comparable to some compiled languages Given that python programs usually run an order of magnitude slower than compiled languages even a 2x performance increase doesn't put it in the "comparable" range from my experience. Not bashing python - I use it regularly - but for computational stuff it's a hog unless you're just passing stuff to C libs - like I have a resource build pipeline that does some blender 3D model t…
Blender Python lib by default is not optimized much. It has nothing to do with Python as a language.
Use numpy for matrices. If you have to implement an algo with a hot inner loop, use cython or numba.
I've never seen 100x difference in Python-C++ rewrite if Python was optimized already.
Here is a good article about some of the options: https://rare-technologies.com/word2vec-in-python-part-two-op...
Re: PyPy v5.8 released
#9I have a question and then a general vent
1. Does anyone know the latest update on NumPyPy? PyPy for me is just not a usable proposition because I heavily use Numpy (and Scipy et al). So I am forced to use slow Python + fast Numpy or slow Numpy + fast Python. Very saddening. The C-Extension is just so off the pace, NumPyPy was meant to solve that quandry.
And I know some smart Alec will trot out the usual 'downshift into C' line that everyone (including Guido) use as the final goto solution for performance but that is simply a disgrace in 2017. Even JavaScript is fast. Why can I not choose to write Python and it be fast?? And yet Python 3 is getting slower. Don't agree? Look at these benchmarks of Python heaps written in Python (not using the C based builtin heapq) https://github.com/MikeMirzayanov/binary-heap-benchmark Python generally is off the pace but Python 3 is about twice as slow as 2 and miles off JavaScript.
But PyPy is proof that Python can be fast. It makes quote/unquote "Pure Python" within striking distance of Go and and when I run that test suit on PyPy, its similar to the Node.js score. Why does this matter? Because I want to write bloody Python not C.
And it is so tantalisingly close - look at a blog post like: https://dnshane.wordpress.com/2017/02/14/benchmarking-python... The performance of the Fibonacci Heap that someone wrote in quote/unquote "Pure Python", when run in CPython can never compete with HeapQ (the C based builtin lib), but on PyPy it can. Fast code written in Python. So what are the problems holding back PyPy? I think possibly money and number of devs working on stuff. Javascript had Mozilla, Google, Microsoft and Apple in a browser war + loads of open source input.
But is the biggest stumbling block not Guido himself and the core Python devs? Do they just philosophically not agree with PyPy or is it just disinterest?
Well whatever it is, it is heart-breaking to want to write fast code in my favourite language and leverage all its power including Numpy/Scipy etc and not be able to. And yes my use-case is perhaps quite unique, a very CPU intensive service that ideally computes and returns a real-time calculation (that includes 500k function calls) in 10-50ms.
But getting fast Numpy in the PyPy mix (i.e all the speed of the JIT + no worse Numpy) would be a HUGE step forward for me in PyPy adoption. What is the latest? How can I help?
Re: PyPy v5.8 released
#10I have a question and then a general vent 1. Does anyone know the latest update on NumPyPy? PyPy for me is just not a usable proposition because I heavily use Numpy (and Scipy et al). So I am forced to use slow Python + fast Numpy or slow Numpy + fast Python. Very saddening. The C-Extension is just so off the pace, NumPyPy was meant to solve that quandry. And I know some smart Alec will trot out the usual 'downshift…
I can't answer how numpypy is going, but Numba works pretty well for me to write fast numeric code in python. A bit restricted language and installing llvm is a bit of a hassle, but overall it's great.