There is so much hate here for the GIL, which is undeserved. You tend to not notice all the nice safety it gives you. If you want to speed up your Python code you could of course try to make it run in parallel: congratulations, you just wasted N times more CPU on slow interpreted code. You could have used an accellerator language like Numba, or write parts of your code in C++ or Rust and get a 10-100 times speedup on a single core!
This is the third time you've replied to someone with this exact comment. Please don't do that. You are not being as effective at promoting your POV as you might be if you were a little more tactful.
I read the document. Sam Gross seems to have a clear grasp on the risks associated with this kind of project (I would quote the relevant part, but google docs is a clown shoe.)
One the one hand I wish him luck. If he pulls it off he'll be a hero. On the other hand this seems like a huge "turd polishing" for a problem that one only encounters if one is doing something ill-advised. The GIL just isn't that big of a problem in practice. I've been writing Python for going on twenty years without ever encountering a single problem due to the GIL.
I replied to comments that seemed ill-informed or hadn't bother to read the design doc. I have been writing Python since January 2000 or so, so I guess I maybe have 2 years on you there.
I haven't encountered any difficulties with the GIL either, but that doesn't mean it's not a problem.
FWIW, I think it's a good thing to encourage people to read the design doc. Ignorant knee-jerk responses help no one and waste a lot of time, and we can have a better discussion if participants are better informed. I don't think you were doing the wrong thing, I felt you were doing the right thing poorly. ("FUD" is pretty strong language IMO in this context.)
I really do hope Gross is successful. It does seem like he's "got an angle", so to speak, on the problem. At the very least, he's coming into it well-informed with his eyes open. He wants to try excising the GIL (and FB is apparently footing the bill to boot) so it's stupid to object, eh? Who cares if he wastes his time? He's not hurting anything. And maybe the horse will learn to sing. :)
The FUD comments came when I was on my phone and in https://xkcd.com/386/ mode. I was just disappointed seeing so many comments that were, well, FUD. FUD may be terse, but I don't think it's strong language.
There's a lot of misunderstanding around the GIL in general.
You can’t just call everything that doesn’t agree with your opinion FUD…
Because, you know, they make a valid (flamebatish) point, the ‘easiest’ way to get performance out of python is to wrap the critical code in another language as an extension. Removing the GIL isn’t going to change this no matter how careful it is designed.
FUD isn't just a meaningless phrase, it means fear, uncertainty and doubt. Nearly every comment against GIL removal makes vague claims about this causing stability issues in a large amount of code that possibly, might, perhaps depend on it without even being aware of it. Yet there is not a single example given that holds up to even basic scrutiny. This is quite literally a textbook case of FUD.
What's the point of "safety" if it's not needed anymore, as it seems not to be under nogil? If that's right, then modulo regressions/bugs possibly introduced by nogil, the choice is really just between worse or better performance, and it's not important whether there are (more effortful, by the way) ways of getting much much better performance.
Moreover, to the point about writing performance-critical sections in $NOT_PYTHON, as Sam Gross explains in the nogil design doc, things aren't always so straightforward for scientific computing:
> Calling into Python from C requires acquiring the GIL -- even short snippets of Python code can inhibit scaling. Addressing this issue sometimes requires rewriting large portions of Python code in C/C++ to actually achieve the desired parallelism. For example, PyTorch rewrote all of the core automatic differentiation from Python to C++ to avoid acquiring the GIL in the backward pass.
