3 ms·

The most obvious performance win for free threading in Python is where you have large read-only, immortal data that is referenced by all threads. The "memory tr

The most obvious performance win for free threading in Python is where you have large read-only, immortal data that is referenced by all threads. The "memory traffic" you mention is a major issue for multiprocessing approaches, and sub-interpreters don't provide access to shared memory in this way, either. The no-gil project has already been benchmarked to scale basically linearly in this scenario, so your hand-waving predictions are already known to be inaccurate. https://www.backblaze.com/blog/python-gil-vs-nogil-boost-i-o-performance-10x-with-one-line-change/ https://www.backblaze.com/blog/python-gil-vs-nogil-boost-i-o...

jerf 3y ago
I'm not talking about the performance that no-GIL is going to get on little bits and pieces of code. I'm talking about the real-world performance it is likely to get on real code. I work in languages that don't have anywhere near the overhead and ceremony that Python does, and when you're writing multithreaded code for the explicit purpose of optimizing some particular bit of slow code, it is quite common to find you completely top out at 3x or 4x performance no matter how many cores you throw at it, because you bottleneck on something other than CPU anyhow. Microbenchmarks in those languages can also get perfectly parallel speedups but that's not what you get in real code. Again, if you're sitting on slow Python code and hoping for the GIL-ectomy to save you, you should just go write it in a different language right now. A perfectly parallel Python will still be slower on a 32 core machine than other languages can be on a single core... and by some margin! The competition I'm benchmarking Python's performance work isn't against other Python approaches, it's against other languages entirely. Subinterpreters are just a concession to the enormous pile of other preconditions Python (and dynamic scripting languages) brings with it and have no bearing on how other languages work; they're a hack around that problem. They're not a solution any other language would consider without those requirements weighing them down.

jerf 3y ago

I'm not talking about the performance that no-GIL is going to get on little bits and pieces of code. I'm talking about the real-world performance it is likely to get on real code. I work in languages that don't have anywhere near the overhead and ceremony that Python does, and when you're writing multithreaded code for the explicit purpose of optimizing some particular bit of slow code, it is quite common to find you completely top out at 3x or 4x performance no matter how many cores you throw at it, because you bottleneck on something other than CPU anyhow. Microbenchmarks in those languages can also get perfectly parallel speedups but that's not what you get in real code. Again, if you're sitting on slow Python code and hoping for the GIL-ectomy to save you, you should just go write it in a different language right now. A perfectly parallel Python will still be slower on a 32 core machine than other languages can be on a single core... and by some margin! The competition I'm benchmarking Python's performance work isn't against other Python approaches, it's against other languages entirely. Subinterpreters are just a concession to the enormous pile of other preconditions Python (and dynamic scripting languages) brings with it and have no bearing on how other languages work; they're a hack around that problem. They're not a solution any other language would consider without those requirements weighing them down.