5 ms·
What are the reasons why nobody uses pypy?
by modeless 1y ago
What are the reasons why nobody uses pypy?
- throwaway314155 1y agoYeah I'm curious about this myself. Seems to utterly destroy CPython in every one of those benchmarks.
- miguelgrinberg 1y agoKeep in mind that the two scripts that I used in my benchmark are written in pure Python, without any dependencies. This is the sweet spot for pypy. Once you start including dependencies that have native code their JIT is less efficient. Nevertheless, the performance for pure Python code is out of this world, so I definitely intend to play more with it!
- redsymbol 1y agoIt currently only supports Python 3.11. That is a big reason.
- lucb1e 1y agoI was happy to see it supports a fairly recent Python3 at all now, like Py3.5 or what is it that ships with most of the expected stuff? Works for me, I'd target something like that for compatibility anyway
- deleted 1y ago[deleted]
- kccqzy 1y agoBecause in the real world, for code where performance is needed, you run the profiler and either find that the time is spent on I/O, or that the time is spent inside native code.
- lenerdenator 1y agoAlso, that engineer time you would spend optimizing for performance costs more than just throwing more hardware at it.
- repsilat 1y agoFor cloud jobs that can be true, but for single threaded dev-in-the-loop work you can't just buy a 100x faster processor than the one on their dev machine, and the latency is expensive workflow friction.
- tehjoker 1y agoNot if you have certain types of scientific data. You can't rent enough hardware to run the slow code.
- morshu9001 1y agoThat's the thing with single threaded CPU operations, you can't throw more hardware at it
- lenerdenator 1y agoIn this situation, "more hardware" would mean throwing a faster CPU at it.
- morshu9001 1y agoIt caps out quickly. If you have a newish Mac, you're already pretty much at the max.
- repsilat 1y agoThis might have been your experience, but mine has been very different. In my experience a typical python workload is 50% importing python libraries, 45% slow python wrapper logic and 5% fast native code. I spend a lot of time rewriting the python logic in C++, which makes it 100x faster, so the resulting performance approaches "10% fast native logic, 90% useless python imports".
- b3orn 1y agoImports being slow is annoying, but only matters to short running code.
- repsilat 1y agoMany simple scripts at my work that more or less just argparse and fire off an HTTP request spend half a minute importing random stuff because of false deps and uncommon codepaths. For some unit tests it's 45 seconds, substantially longer than the time taken to run the test logic. In dev cycles most code is short-running.
- nickpsecurity 1y agoHave you thought about packing that stuff into an executable or precomputing or preloading it? There's techniques for each of those things that help in some scenarios.
- instig007 1y ago> Many simple scripts at my work [...] For some unit tests it's 45 seconds > I spend a lot of time rewriting the python logic in C++, which makes it 100x faster Nice! Your workplace didn't care to pick a better tool for the job in the past, and it seems to not care what you're doing at present, if you have to spend time rewriting the stuff in C++, instead of picking Nim and calling it a day, in a day.
- cb321 1y agoEven better, in Nim these little CLI tools could use https://github.com/c-blake/cligen https://github.com/c-blake/cligen and have had terminal colorized, auto-generated help for many years now with much less dev-effort than raw argparse. Start-up time of statically linked Nim programs is like O(100..500 microseconds, just like C programs).
- lucb1e 1y agoWhen it's a drop-in replacement, as in most of my code (and it's dead simple to try if it runs when you use pypy ./main.py), I wouldn't know why you should run the code 5-50% slower for no reason though
- jonstewart 1y agoI do a bit of performance work and find most often that things are mixed: there’s enough CPU between syscalls that the hardware isn’t being full maximized, but there’s enough I/O the CPUs aren’t pegged either. It is rare that the profiler finds an obvious hotspot that yields an easy win; usually it shows that with heavy refactoring you can make 10% of your load several times faster, and then you’ll need to do the same for the next 10% and so on. That is the more typical real world for me, and in that world Python is really awful when compared to rewrite-it-in-Rust.
- tialaramex 1y agoThis "There are no hot spots, it's just a uniform glowing orange" situation is why Google picked C++ and then later Rust and to some extent why they picked Go too.
- jonstewart 1y agoI am, indeed, a C++ developer. :-)
- morshu9001 1y agoIRL you will have CPU-bottlenecked pure Python code too. But it's not enough to take on the unknown risk of switching to a lesser supported interpreter. Worst case you just put in the effort to convert the hot parts to multiprocessing.
- deleted 1y ago[deleted]
- rootusrootus 1y agoWe look periodically and pypy is usually unusable for us due to third-party library support. E.g. psycopg2, at least as of a couple years ago. Have not checked in a while.
- throwaway7783 1y agopypy has a c-extension compatibility layer that allows running psycopg2 (via psycopg2cffi) and similar for numpy etc.
- ActivePattern 1y agoIt doesn't play nice with a lot of popular Python libraries. In particular, many popular Python libraries (NumPy, Pandas, TensorFlow, etc.) rely on CPython’s C API which can cause issues.
- jszymborski 1y agoFWIW, PyPy supports NumPy and Pandas since at least v5.9. That said, of all the reasons stated here, it's why I don't primarily use PyPy (lots of libraries still missing)
- pletnes 1y agoBut pypy doesn’t necessarily perform as well, and it can’t jit compile the already compiled C code in numpy, so any benefits are often lost.
- gwking 1y agoSpeaking only for myself, and in all sincerity: every year, there is some feature of the latest CPython version that makes a bigger difference to my work than faster execution would. This year I am looking forward to template strings, zstd, and deferred evaluation of annotations.
- semiinfinitely 1y agobecause it turns out that optimizing performance of a programming language designed for use-cases where runtime performance doesn't matter ... doesn't matter
- lucb1e 1y agoMight as well take the work that's already done though? I can't think of a logical reason why you'd want to run it at potentially half the speed (depending on the hot code specifics how much, if any, speedup you get of course)
- morganherlocker 1y agoThere's currently talk of adding gigawatts of data center capacity to the grid just for use cases where python dominates development. While a lot of that will be compiled into optimized kernels on CPU or GPU, it only takes a little bit of 1000x slower code to add up to a significant chunk of processing time at training or inference time.
- deleted 1y ago[deleted]
- MobiusHorizons 1y agoWhat percentage of the CPU cycles are actually spent running Python though? My impression is _very_ low in production LLM workloads. I think significantly less than 1%. There are almost certainly better places to spend the effort, and if it did matter, I think they would replace Python with something like C++ or Rust.
- dec0dedab0de 1y agoBecause it hasn't been blessed by the PSF. Plus it's always behind, so if you want to use the newest version of framework x, or package y then you're SOL. Python libraries used to brag about being pure Python and backwards compatible, but during the push to get everyone on 3.x that went away, and I think it is a shame.
- TheCondor 1y agoI use it where I can, unfortunately those places are usually scripts that don’t benefit from the compiler. The project is moving into maintenance mode, if some folks want to get python-famous, go support pypy.
- nickelpro 1y agoPersonally: cpyext always lags changes in the CPython ABI and headers which my code relies on, or I'm relying on internals which cpyext doesn't implement at all
- lucb1e 1y agoI keep wondering the same. It's a significant speed-up in most cases and equally easy to (apt) install For public projects I default the shebang to use `env python3` but with a comment on the next line that people can use if they have pypy. People seem to rarely have it installed but they always have Python3 (often already shipped with the OS, but otherwise manually installed). I don't get it. Just a popularity / brand awareness thing I guess?
- mort96 1y agoA lot of Python use cases don't care about CPU performance at all. In most cases where you do care about CPU performance, you're using numpy or scikit learn or pandas or pytorch or tensorflow or nltk or some other Python library that's more or just a wrapper around fast C, C++ or Fortran code. The performance of the interpreter almost doesn't matter for these use cases. Also, those native libraries are a hassle to get to work with PyPy in my experience. So if any part of your program uses those libraries, it's way easier to just use CPython. There are cases where the Python interpreter's bad performance does matter and where PyPy is a practical choice, and PyPy is absolutely excellent in those cases. They just sadly aren't common and convenient enough for PyPy to be that popular. (Though it's still not exactly unpopular.)
- CivBase 1y agoI've never experienced any problems that could be attributed to the speed of my Python runtime. I use Python a lot for internal scripting and devops work, but never in a production environment that scaled beyond a few hundred users. I suspect most Python usecases are like that, and CPython is just the safest option.
- bjourne 1y agoCan't run PyTorch on PyPy.
- Asooka 1y agoBecause all the heavy number-crunching code is already written in C or Rust or as CUDA kernels, so the actual time spent running Python code is miniscule. If it starts to matter, I would probably reach for Cython first. PyPy is an extremely impressive project, but using it adds a lot of complexity to what is usually a glue language. It is a bit like writing a JIT for Bash.
- nhumrich 1y agoWe want the new features more than we want performance! Also: there are some libraries that just don't work on pypy.
- eightys3v3n 1y agoIt's not easily available in uv. Even if I installed it outside uv, it always seems significantly out of date. I'm running code in spaces where with uv I can control all the installs of Python, so I don't benefit from using an older release for compatibility.
- ActorNightly 1y agoThe advantage of core python is that you import stuff and 99.999999% of the time it works. With PyPy not so much.
- MobiusHorizons 1y agoI think generally people who care about performance don't tend to write their code in Python to begin with, so the culture of python is much less performance sensitive than is typical even among other interpreted languages like perl, php, ruby or javascript. The people who do need performance, but are still using python, tend to rely on native libraries doing significant numerical calculations, and many of these libraries are not compatible with PyPy. The escape hatch there is to offload more and more of the computation into the native runtime rather than to optimize the python performance.
- deleted 1y ago[deleted]