Hacker News new | past | comments | ask | show | jobs | submit login
PyPy gets a new RISC-V JIT back end (pypy.org)
60 points by fork-bomber 14 days ago | hide | past | favorite | 14 comments



I've seen Python in use at various places and I've been hearing about PyPy for years and years but I've never seen anyone using it. Who does use it, and why don't more people use it?

I've used it a few times, I had a little script that processed a big important JSON file in functional test. PyPy is pretty easy to setup, and it's free 5-10x that lets you iterate faster as soon as you start to have bigger input files

At some point if it's a heavy process that has to run often, I would probably have rewritten it in Rust or something else, but in this case that script only needed to run a few times, and it needed to be correct, hence the heavy tests before running it for real

I think of PyPy more as making the dev feedback loop faster, rather than something I'd run in prod


> Who does use it

"Ask HN: Is anyone using PyPy for real work?" (2023, 181 comments) can give you an idea: https://news.ycombinator.com/item?id=36940871. You notice a pattern in the comments. People use PyPy for the unglamorous task of speeding up some existing Python code instead of rewriting it. It isn't surprising they don't blog much about it.

> and why don't more people use it?

As other comments have already said, the incompatible binary extensions.


I try it every now and then. Unfortunately it's not that fast and struggles with binary packages, although that's getting better. It can also be a bit of a hurdle to install, although that's better nowadays too.

For some cases, e.g. large scale string processing, it may bring substantial benefits. For e.g. numerical stuff with numpy usually not, and for that there are a lot faster options (e.g. numba).

In the end Python is really slow, and even with PyPy it's usually slow to really slow. For other than numerical stuff it's better to usually go with e.g. Node.


It's not more used because of c extensions, mostly.

If you have a long running process with a lot of pure python code, you can get a lot of perf boost.

Be aware memory consumptuon will go up significantly.


I suspect, even for people who know about pypy and have programs that would benefit from using it and can use it, the main thing is defaults. Generically running on Python (only recently Python3) means you run and forget about it on pretty much any target. But installing pypy (or making any changes to defaults) on some k8 image or whatever is enough of a hassle and people just shrug.

There are official pypy docker images on docker hub, from what I recall.

I’ve seen it used in backend systems processing lots of small events. Never noticed any python/pypy difference. I guess it can be used for many things but package selection is smaller and most people don’t know about it.

I’ve also heard that python is bad because it doesn’t support static typing, but it does. Most people only know about a tiny fraction of all the options out there.


I've never used it because I only use Python when speed really really doesn't matter and I don't want to have to deal with potential compatibility issues. If speed matters even in the slightest, or might matter in future, then I'll just use a faster language like Rust, Go or Typescript.

Because most people rather rewrite their code into C and keep calling it Python libraries still.

or by now rust

it's surprisingly convenient to do


Having done so for many years in Tcl, I rather have a JIT or AOT toolchain in the reference implementation, regardless of how easy it is to use the C FFI.

in general I agree not having to write external extensions/plugins is always better then having to write them no matter how easy it is

but that isn't the design path python choose (in general, PyPy did choose that path)


PyPy is great for loopy/branchy code with lots of function calls. Things that you haven’t done the mental gymnastics to vectorize. That being said, in my line of work, when Python is the bottleneck, a little bit of numpy goes a long way, especially if you orient your axes around the reductions you have planned.

The other thing I’ll say for pypy is that by demonstrating that a Python interpreter written in Python can be faster than Python, it’s pushed CPython to improve performance as well. Not that CPython developers wouldn’t pursue performance gains on their own, but pypy offers a specific target, and we’ve all benefited from the comparison.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: