I have a question and then a general vent<p>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.<p>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) <a href="https://github.com/MikeMirzayanov/binary-heap-benchmark" rel="nofollow">https://github.com/MikeMirzayanov/binary-heap-benchmark</a> Python generally is off the pace but Python 3 is about twice as slow as 2 and miles off JavaScript.<p>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.<p>And it is so tantalisingly close - look at a blog post like: <a href="https://dnshane.wordpress.com/2017/02/14/benchmarking-python-heaps/" rel="nofollow">https://dnshane.wordpress.com/2017/02/14/benchmarking-python...</a> 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.<p>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?<p>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.<p>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?
PyPy 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.
Coming from someone who uses python but doesn't really follow alternative compilers, PyPy sounds great. What are some of the downsides, if any? Are you sacrificing library compatibility for faster core+standard libs?
Why are they still comparing to Python 2.7.2? I couldn't find benchmarks against Python 3.5 for their Py3 interpreter.<p>All the times I tried PyPy I came into a hurdle where one of the libraries I needs doesn't work (or underperforms) in PyPy, the most important ones being Numpy and OpenCV.<p>So in the end I just gave up with them, and stuck with Python 2/3 and Cython, which solved my speed problems without having to do all the work of C-extensions from the ground up.<p>Edit: the one benchmark I found covering PyPy3 is this: <a href="https://pybenchmarks.org/u64q/benchmark.php?test=all&lang=pypy3&lang2=python3&data=u64q" rel="nofollow">https://pybenchmarks.org/u64q/benchmark.php?test=all&lang=py...</a><p>It shows PyPy3 5.7.1 being about 8x faster to 100x slower than CPython 3.6.1.<p>For comparison, PyPy2 5.7.1 ranges from 10x faster to a bit over 30x slower to than CPython 2.7.13.
Any word on the "single codebase" aspect of supporting both major Python versions? I remember suggesting it years ago at a time when the team wanted to do Mercurial backporting instead. What changed their mind?<p>That looks like it could fix the lag on CPython releases, so it's a big feature.