6 ms·
> There is going to be a performance impact on single threaded code if the "no GIL" project is merged, something in the region of 10%. 10% doesn't look too muc
by vb-8448 3y ago
> There is going to be a performance impact on single threaded code if the "no GIL" project is merged, something in the region of 10%.
10% doesn't look too much to me, I still don't get why today people care so much about single thread performance.
- samwillis 3y agoExactly, and the thing is, the Faster Python project will completely surpass that 10% performance change.
- _kulang 3y agoSometimes people see it as losing 10% performance that you never get back
- awill 3y agobecause a lot of code is single-threaded
- celeritascelery 3y agoSingle threaded performance is still more important than multi-threaded. Most applications are single threaded, and single threaded programs are much easier to write and debug. Removing the GIL from python will not change that. If no-GIL has a 10% single thread performance hit, that means that essentially all my existing python code would be that much worse.
- hospitalJail 3y agoAre your current python programs slow and it matters? Why havent you implemented multithreading? (don't get me wrong, I know the cost of implementation, but if speed matters, multithreading is a very reasonable step in python)
- birdyrooster 3y agoBecause the GIL and also you have to use tons of locks to get around the lack of thread safety for pythons objects.
- deleted 3y ago[deleted]
- Spivak 3y ago> Why haven't you implemented multi-threading? Because that makes programs slower in Python. Multi-threading in Python is for when you need time-slicing for CPU intensive tasks so that they don't block other work that needs to be be done.
- coldtea 3y agoHis point remains, he just phrased it badly. We haven't you implemented a multiprocess pool?
- gpderetta 3y agoBecause not everything is trivially parallelizable and multiprocess makes it harder to share data?
- coldtea 3y ago>Because not everything is trivially parallelizable A lot of things are though...
- munch117 3y agoBecause it's a global solution to a local problem. With threads, I can encapsulate the use of threads in a class, whose clients never even notice that threads are in use. Sure, threads are a global resource too, but much of the time you can get away with pretending that they're not and create them on demand. Not so with multiprocess. If you use that, then the whole program has to be onboard with it. Threads work great in Python. Well not for maximising multicore performance, of course, but for other things, for structuring programs they're great. Just shuttle work items and results back and forth using queue.Queue, and you're golden - Python threads are super reliable. And if the threads are doing mostly GIL-releasing stuff, then even multicore performance can be good.
- vb-8448 3y ago> If no-GIL has a 10% single thread performance hit, that means that essentially all my existing python code would be that much worse. Maybe in a 100% CPU bound code, most of the code is I/O bound and no one will notice the change, just my opinion.
- burnished 3y agoIt might be more helpful to think of it in terms of supported use cases, rather than just pure volume.
- wongarsu 3y agoMaybe that's just my bubble, but I see much more python in data science projects than in web servers. And in (python) data science even your file reading/writing code quickly gets CPU bound.
- baq 3y agoThere was a time like 5-10 years ago where Python was really popular for grassroots web projects. Nowadays this is mostly node looks like.
- coldtea 3y agoNot in pure Python, that's in specialized libs, like numpy, pandas and co, done in C. So, the hit on the Python interpreter wouldn't translate to a hit on those.
- regularfry 3y agoThat's going to be CPU-bound in numpy's C extensions rather than Python itself, one would hope. The worst of all worlds is that we get a 10% perf cut to python execution and numpy breaks because the C API is ripped up.
- gpderetta 3y agoThat's because you are doing it wrong. You'll need to split every step of your data science pipeline into a microservice, then put it in the cloud for resilience. Then the application will be so fast that it is no longer CPU bound but I/O bound.
- coldtea 3y ago>If no-GIL has a 10% single thread performance hit, that means that essentially all my existing python code would be that much worse. So? Especially since the "Faster Python" team already made Python 1.11 "10–60% Faster than 3.10", and 1.12 is even faster still, whereas their overall plan is to get it to 2-5 times faster compared to 3.9. So at the worst case, with a 10% hit, you'd balance out the 3.11 speed, and your code would be as fast as 3.10.
- shpx 3y agoBut your software would still run 10% slower than it needs to. Single threaded code is like 99% of all code written.
- gpderetta 3y agothat's not an argument either, as your software is already 10000% slower than it needs to be as you have written it in python.
- deleted 3y ago[deleted]
- coldtea 3y ago>But your software would still run 10% slower than it needs to There's no absolute objective "needs to" or even any static baseline. Python can have, and often has had, a performance regression that drop your code by 10% at any time. It's no big deal in itself. Also consider a further speedup of e.g. 50% in upcoming versions (they have promised more). If you're OK with the X speed of today's Python, you should be ok with X + 40% - even if it's not the X + 50% it could have been due to the 10% GIL's removal toll.
- ahoho 3y agoRight, and single thread performance won’t matter as much if it becomes easier to implement multithreading. This hurts legacy code, but I imagine it would be worth it in the long run.
- bombolo 3y agoIt would remain as hard as it has always been. Also threads are very heavy, locking kills performance, and if you don't have GIL, you'll need to manage explicit locks, that will be just as slow but also cause an incredible amount of subtle bugs.
- saltminer 3y ago> locking kills performance, and if you don't have GIL, you'll need to manage explicit locks I was under the impression that the Python thread scheduler is dependent on the host OS (rather than being intelligent enough to magically schedule away race conditions, deadlocks, etc.), so you still need to manage locks, semaphores, etc. if you write multi-threaded Python code. I don't see how removing the GIL would make this any worse. (Maybe make it slightly harder to debug, but at that point it would be in-line with debugging multi-threaded Java/C/etc. code.) Or would this affect single-threaded code somehow?
- bombolo 3y agoIn python you always have a lock, the GIL. If you take it away you end up actually having to do synchronization for real. Which is hard and error prone.
- deleted 3y ago[deleted]
- pdonis 3y ago> if you don't have GIL, you'll need to manage explicit locks You need to do that with multithreaded Python code with the GIL. The GIL only guarantees that operations that take a single bytecode are thread-safe. But many common operations (including built-in operators, functions, and methods on built-in types) take more than one bytecode.
- hospitalJail 3y ago>I still don't get why today people care so much about single thread performance. For about 10 minutes a few years ago, when the M1 had the best single threaded performance per buck, people cared. Now that the M1 isnt the leader in single threaded, we are back to the 'multithread is most important'. Which has always been true. If your program needs an improvement in speed, you can multithread it. The opposite isnt true.
- holoduke 3y agoNot all algorithms can be chunked up. Single thread performance is and will always be important.
- Joker_vD 3y ago> If your program needs an improvement in speed, you can multithread it. The opposite isnt true. What do you mean by "the opposite"? "If your program doesn't need an improvement in speed, you can't multithread it"? "If you can multithread your program, then it doesn't need an improvement in speed"? Well, yeah, obviously both of those statements are false but they're also quite useless, so who cares?
- insanitybit 3y agoYou can improve performance by moving to a single thread. Pinning work to a single core will improve cache performance, avoid overhead of flushing TLBs and other process specific kernel structures, and more.
- david422 3y agoAnd if you're really concerned about speed, Python is not the language to choose.
- burnished 3y agoEvery program in any language has the potential to be concerned about speed. This cute maxim is ultimately a punchline, not really a serious point.
- crabbone 3y agoCPython is so hopelessly slow, I wouldn't care about 10%. For most of the stuff written in Python, users don't really care about speed. The impact won't be on users / Python programmers who don't develop native extensions. It will suck for people who had a painful workaround for Pythons crappy parallelism already, but now will have to have two workarounds for different kinds of brokenness. It still pays off to make these native extensions, however their authors will create a lot of problems for the clueless majority of Python users, which will like end up in some magical "workarounds" for problems introduced by this change very few people understand. This will result in more cargo cult in the community that's already on the witch hunt.