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 t

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.