Do people here use pypy in production? What are the benefits?
We've been running a very large production PyPy deployment across pretty much all our Python apps for about... 4 years now. Saves us a ton of money for essentially no real downside.
Let's Remove the Global Interpreter Lock
31–40 of 326 posts
Re: Let's Remove the Global Interpreter Lock
#32Could someone who really wants to get rid of the GIL explain the appeal? As far as I understand, the only time it would be useful is when you have an application that is 1. Big enough to need concurrency 2. Not big enough to require multiple boxes. 3. Running in a situation that can not spare the resources for multiprocessing. 4. You want to share memory instead of designing your workflow to handle messages or workin…
In my five years of python I've run up against this boundary at least once. In your list I would
* take out #2. if something can make use of multiple nodes it can usually make even better use of multi-core parallelization (which affects both computational and memory bandwidth performance). multi-node comes with a much higher communications overhead, so there's a relatively wide range of applications that scale well on multi-core but not multi-node.
* add that #3 comes up as soon as you have complex data structures to share. Serializing and Deserializing (by default with pickle) is a huge overhead for anything a bit more involved. If you design for this from the start you can be fine, but often these things grow and eat up bigger and bigger usecases until you run against the GIL. This basically happens with anything that has enough data and users and need - hey I heard your scheduler tool works well for the cafeteria, I'm sure it can handle our global operations right?
* about #4 - see the previous point.
Re: Let's Remove the Global Interpreter Lock
#33Earlier quoted context omitted.
Using multiprocessing is a pain to use, and it's slow.
in what was is it a pain that threading is not?
With threading, all of your threads can refer to the same objects. Multiprocessing means you have multiple interpreters running. That means no shared memory, and communication over pretty slow queues. I've definitely wanted to have multithreaded Python programs where all threads referred to the same large read-only data structure. But I can't do this because of the GIL. I mean, I can, but it's pointless. I can't do this with multiprocessing because of the limitations on shared memory with multiprocessing.
Edit: I realize I'm contradicting myself here. No shared memory is a first approximation. You can have shared memory with multiprocessing, but most objects can't be shared.
Re: Let's Remove the Global Interpreter Lock
#34Do people here use pypy in production? What are the benefits?
Sure. Free 2-5x speedup. pypy + pypy's pip generally works as a transparent drop-in replacement to python + python's pip, so it's free speed. It doesn't (or didn't) work when you need to rely on an extension that uses Python's C API. I haven't followed the scene in awhile so maybe that's changed. pypy's pip has so many libraries that I hardly notice, so maybe they solved that. Unfortunately python is fundamentally sl…
I can't tell what you mean by the last paragraph there, but oftentimes PyPy's speedups come exactly from inlining stuff like what you refer to there -- Python's not fundamentally slower, it's those kinds of stuff that you can speed up.
(And yeah the CPython API is still a pain point if you've got a library that uses it, although some stuff will still work using PyPy's emulation layer. It'd be great if people stopped using it though.)
Re: Let's Remove the Global Interpreter Lock
#35This would be great if it means we can run the C portions of Python in threads without performance hits. I recently started a little project that is a cross-platform GUI for batch bzip2 compression, and Python did it quite well with its built-in bzip2 module. But, once I tried to do it parallel, the performance impacts of GIL were obvious. Yes, you can work around that with multi-process, but I'd rather not be spammi…
In normal CPython, you can design your C extension (such as bzip2) to release the GIL while it runs. This is one of the few times when threads are useful in Python. It's also why scipy etc are as fast as they are.
I don't know if the bzip2 module does this, but it probably should.
Re: Let's Remove the Global Interpreter Lock
#36Earlier quoted context omitted.
As mentioned in the blog post the individual donation buttons are not a resounding success. I'm happy to sign contracts with corporate donors (or even individuals) that we'll deliver. My mail should be public, if not #pypy on freenode or fijal at baroquesoftware.com
Is the issue that individual donations are unpredictable (and therefore difficult to use as justification for such a large scope increase)? Would you consider setting up something akin to a Patreon to allow individuals to commit to recurring monthly support for the project?
The main issue is that the effort it takes to setup and maintain it greatly outweighs the amount of money we get (typically). There is also complexity with taxation, jurisdictions and all kinds of mess that is usually very much not worth couple dollars (e.g. $7/week on gratipay for example)
Re: Let's Remove the Global Interpreter Lock
#37Do people here use pypy in production? What are the benefits?
We do. 2x speedup.
Re: Let's Remove the Global Interpreter Lock
#38Just curious: if they solve it in Python, would it be possible to solve it in Ruby too ?
It is already solved for Ruby when you use JRuby.
Re: Let's Remove the Global Interpreter Lock
#39Earlier quoted context omitted.
Sure. Free 2-5x speedup. pypy + pypy's pip generally works as a transparent drop-in replacement to python + python's pip, so it's free speed. It doesn't (or didn't) work when you need to rely on an extension that uses Python's C API. I haven't followed the scene in awhile so maybe that's changed. pypy's pip has so many libraries that I hardly notice, so maybe they solved that. Unfortunately python is fundamentally sl…
I can't tell what you mean by the last paragraph there, but oftentimes PyPy's speedups come exactly from inlining stuff like what you refer to there -- Python's not fundamentally slower, it's those kinds of stuff that you can speed up. (And yeah the CPython API is still a pain point if you've got a library that uses it, although some stuff will still work using PyPy's emulation layer. It'd be great if people stopped…
For example, Python makes it fairly easy to trap a call to a missing method, both via __getattr__ and __missing__. In JS the only way you can do that is via Proxy objects, and even those have limits.
You can't always inline the arithmetic ops effectively. You can recompile the method each time it's called with different types, but that's why the warmup time is an issue. This wouldn't be a problem if Python didn't make it so trivial to overload arithmetic. JS doesn't.
Re: Let's Remove the Global Interpreter Lock
#40This would be great if it means we can run the C portions of Python in threads without performance hits. I recently started a little project that is a cross-platform GUI for batch bzip2 compression, and Python did it quite well with its built-in bzip2 module. But, once I tried to do it parallel, the performance impacts of GIL were obvious. Yes, you can work around that with multi-process, but I'd rather not be spammi…
[deleted]