The 2021 workstation I am typing this on has 16 physical and 32 virtual cores, and I expect core counts to continue upward this decade. While the CPython core devs may be excellent programmers and do a good job at maintaining Python, they clearly have a bit of trouble with cost/benefit analysis if the complaint is that the test count will double in CI for a ~16X increase in the amount of code that can be run in parallel on even consumer machines. Yes, yes, I know that this does not mean my programs will run ~16X as fast. Yes, I know there are other objections. But this is an order of magnitude away from being an actual blocker and the fact it was brought up at all as an objection shows a fundamental disconnect between the small potential costs imposed on core devs, and the huge potential upsides for Python users everywhere.
You can already use multiple cores by writing C extensions that release the GIL and with multiprocessing. That double CI cost and additional work isn't just for core python but for the entire ecosystem.
I chose Python to not have to write C...
The even more sucky part is to distribute them and make sure it works on every OS, without every user having to apt install build-utils before they can pip install your package and then spend rest of the day debugging some rare compilation error because of a header file mismatch with what’s installed on the system. The python packaging space is already complicated enough even without considering native modules.
True shared memory threads within a single process would be a major boon.
b) Introducing native extensions means deployment and distribution becomes more difficult, and introduces a whole new and large class of issues and caveats into a project.
c) Native extensions are not written in Python. (Yes, Cython exists, no, it's usually not a good idea to write more than glue in it).
Don’t use Python is also my preferred recommendation when I encounter Python.
1. Learning a new language is non-trivial for many people (and don't sneer - it's about time not competency)
2. The ecosystem matters. If the code you want to interface with is in Python then "don't use Python" is just glib.
I'm mainly proficient in Javascript, Python and C#. My choice of language is rarely based on "which is best for this task?" but mostly "want do I need to run on and interface with?"
I could imagine getting pretty jaded as a python maintainer having to keep pointing out why the latest attempt won't work. I think the onus is on those who want this to demonstrate that it can be done successfully and lay out a plan as to how it can be put into the real world without causing chaos in a python ecosystem that has only relatively recently got over the trauma of python 3 (which is the bit I doubt is possible).
Edit: To be clear, I don't think anything that consists of a set of proposed changes to the cpython interpreter is even beginning to attempt to think about the implications for the ecosystem, which is where the actual challenges are, and I'm assuming that's what the "Just creating a PR" comment is saying.
⇒ I don’t see this as a team of worn-down maintainers, but rather as a team of seasoned developers, who know you don’t turn a project with millions of users around on a dime.
One question I miss is whether the set of locks this change introduces is the optimal one.
I would think that, if it were to be improved upon in the future, C extensions would have to be changed again, so you’d rather not do that often.
Hasn’t this gil/nogil saga been going on for ~decades? What about fixing packaging or limiting the C-extension interface? I have enormous sympathy of what the Python maintainers are up against, but “on a dime” seems hard to justify.
That's numpy, pandas, sklearn, and friends.
If it's such a huge game changer why don't some of the large enterprises which rely on Python fund this work?
I would hazard a guess to say that 99% of production Python is people doing the equivalent of welding, but there is also this 1% who want the GIL to be gone so they can repurpose Python as a tool for a whole new class of problem solving.
It will be an exciting future for them.
For us welders, we’ll carry on gluing stuff together blissfully unaware of the GIL. Async and non-blocking IO are great. I don’t think I’ve ever needed compute-concurrency, not in Python anyway.
If there wasn't the GIL, I could just create a thread pool and be done, and Cura could continue to be a delightful mess. :-)
Some are so compute heavy that massive amounts of time is put into tuning them (sort algorithms, fast-fourier transforms, etc).
Most fall somewhere on the spectrum between those extremes. If you can speed up your program by a factor of 20 by adding threads, Python can cover a bit more of that in-between spectrum.
As for the C, C++, Fortran libraries with Python bindings, any language with FFI can call into them as well.
I would say, Python's adoption while lacking performance is what is now building pressure to avoid specific Python communities to leave Python and migrate into one of those ecosystems in search of a better mix of productivity/performance, without being forced to use two languages.
And Clojure also has a .NET implementation.
But it is being continuously kept up to date by Cognitect, along with active development on a clojure-clr-next version. Maybe it has a bigger population of non public users.
This isn't a case of "x" or "y". There is literally nothing valuable about the GIL, it's an ugly hack of a vestigial appendage. Perhaps the reason I'm familiar with it is because the lack of elegant MP threading in Python perturbed me for years, until I was introduced to Golang.
Python devs generally don't want to use Java, JavaScript, etc. And the Go ecosystem is good but not as rich as Pythons.
Anyhow, take care pjmlp. Until our paths cross again I wish you all the best!
JavaScript, Java, .NET, C and C++ are where to look for, if you want to count package numbers, for AOT/JIT languages.
Just because python isn't the fastest language in the world, does not mean that making it easier / possible to write faster python is worthless.
I ported it to Python, with a totally naive simple single threaded loop. It worked perfectly. 25 updates a second, forever. No C code, except the interpreter doing its thing, and some GPIO code.
That's not slow as molasses.
> My page load time dropped from 77ms to 47ms when I ran some of the code in parallel.
I suspect some of us welders will also find some improvements here.
More than 5x can be achieved with the GIL included (and has been promised, by the new Microsoft Python-speed-up initiative and that Python dev who made a similar proposal).
I have. Some very inexperienced “senior engineers” at my last gig thought it would be fine to build an analytics platform in Python because “Pandas will make it fast”. Unfortunately even modest datasets would cause timeouts and even seize the event loop, while a naive Go prototype would finish in a few hundred milliseconds.
No, I don't, and can't find any writing about this at all, do you have any links? Because that sounds amazing
This:
generate fullerene "arc weld"
https://discuss.python.org/t/official-list-of-core-developer...
https://pyfound.blogspot.com/2021/07/ukasz-langa-is-inaugura...
Because lots of code in python relies on the GIL to act as a synchronization primitive for threaded code (either explicitly or implicitly) and removing the GIL will break that code in subtle ways and there’s no appetite in those companies to fix that.
That is just not true.
1 - This helps parallelize regular python code too, like the kind that goes into writing web services.
2 - While you'd still write native extensions to get optimum performance for single threaded code, having the thread dispatch layer in python makes parallelizing execution convenient and robust. For example, see the comment from people who maintain scikit-learn below. I'd love to see python get composable task parallelism like Julia where you can freely spawn threads within threads without worrying about their lifetimes.
link: https://github.com/colesbury/nogil/issues/36#issuecomment-10...
> helps parallelize
> convenient and robust
So nice but not too noticeable?
What percentage of compute time is python?
What percent of Py compute time would be cut?
Who's using python?(banks, stem researchers, everyone else)
> ...bunch of questions...
Yeah, if you claim that something is a "game changer" you should provide some arguments, not questions/"help determine".
It might very well be a game changer but thud far you have only suggested there might be an argument for that, if ...
Edit: For backend services it would probably put Python around one order of magnitude away from Go in terms of memory usage to serve the same load, enough for teams not to consider switching.
Currently, that doesn't do much. Trying to do this with a processPool either works, or becomes a horrible exercise in fighting with pickle or whatever other serializer you pick.
What would I do differently? Actually make engineering choices based on the current project status and priorities without having those choices made for me.
Otherwise, there’s making a fork and attempting periodic updates from python. That’d be a huge undertaking though.
FTA: “”” A lot of the value of Python is the ecosystem, not just the language… CPython really leads the way in terms of the community moving as a block.
"Removing the GIL is a really transformative step. Most Python programs just don’t use threads at the moment if they want to run on multiple cores. If nogil is to be a success, the community as a whole has to buy into it."
– Sam Gross”””
edit: not sure why I got flagged, HN. Software engineer hours == funding.
[0]https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[1] https://docs.python.org/3/library/multiprocessing.shared_mem...
It looks like they are supportive and keen on the changes? From the article:
> Gross's proposal was greeted with a mix of excitement and robust questioning from the assembled core developers.
It's definitely a huge opportunity, no doubt. But it affects the C ABI[1] for Python itself, something that everyone in the conversation is aware of, and that would have implications for all distributions of Python.
Add in the importance of effective code review for a 20k LoC changeset, and it seems there are good reasons to be cautious despite the optimism and excitement.
[1] - https://docs.python.org/3/c-api/stable.html#stable-applicati...
Sometimes you just get lucky.
No, it’s not. My comment applies to single threaded performance as well (I wasn’t even thinking about the GIL when I made my comment)—why isn’t Python as fast as modern JS implementations, for example? The answer isn’t “JS has multi thread support”.
Moreover, a slim C extension interface is about flexibility so you don’t paint yourself into a corner when you don’t know what the world might look like tomorrow. Further, you can have a very rich C extension API without exposing the entire interpreter (e.g., h.py). Further still, Python has broken compatibility several times since its inception, so the idea that this was cemented in 91 is nonsense.
Because the project has explicitly targeted implementation simplicity, largely successfully, for almost 30 years. The internals are a joy to work on, and unsurprisingly the CPython Git repository has 4x as many contributors as v8, despite CPython contribution being largely voluntary and v8 contribution being largely commercial.
Even if performance were an explicit goal, it's important to remember v8 required absolutely massive funding and top tier engineering support to make it happen at all. The most comparable equivalent in the Python world, PyPy, was the product of an extremely dedicated group of mostly doctoral researchers working against incredible odds. V8 only has 2x as many contributors as PyPy. I hope by now you are recognizing a theme: the reason the language is so successful is also the reason we are here complaining about it.
There have been teams in at least Google and Dropbox who proposed major upheavals of the interpreter in the past. Both failed in large part due to the complexity of their proposals compared to the performance gains on offer
> The most comparable equivalent in the Python world, PyPy, was the product of an extremely dedicated group of mostly doctoral researchers working against incredible odds
"incredible odds" refers to compatibility with the CPython C-extension interface, which is exactly what I'm talking about.
> There have been teams in at least Google and Dropbox who proposed major upheavals of the interpreter in the past. Both failed in large part due to the complexity of their proposals compared to the performance gains on offer
No, they failed because they had to work within the considerable constraints imposed by historically bad decisions (such as the C-extension interface). The proposals need to be complex because they can't break compatibility.
> I hope by now you are recognizing a theme: the reason the language is so successful is also the reason we are here complaining about it.
Not at all! A narrower C-extension interface doesn't imply that C-extensions would be more difficult to write. There are no downsides to a narrower interface (apart from breaking compatibility, but we're positing a world in which this decision was made in 2008 or earlier).
The real theme here is that historical bad decisions + compatibility guarantees add significant complexity to every single improvement if they don't preclude them altogether.
Here's a 2007 essay by van Rossum on the topic: https://www.artima.com/weblogs/viewpost.jsp?thread=214235 .
> I'd welcome it if someone did another experiment along the lines of Greg's patch (which I haven't found online), and I'd welcome a set of patches into Py3k only if the performance for a single-threaded program (and for a multi-threaded but I/O-bound program) does not decrease.
This is the first suggestion that doesn’t degrade single threaded performance.
Why is that unfortunate? If his patch being slower than python 3.11 isn't acceptably fast despite being faster than every other python version before that then python was never acceptably fast to begin with.
Linux got rid of the BKL ages ago, that the Python community still holds onto the GIL as if it was some multi threading holy grail isn't even remotely funny anymore.
If "Python 3.11+faster-cpython" didn't also remove the GIL, then it didn't negate anything he's trying to acomplish. He wasn't going for a faster Cpython alone, but for a Cpython without GIL.
[1] 3.7.0 is the first major release following the removal of the config option in https://github.com/python/cpython/issues/75551 .. there's also a 2021 comment about "This has unfortunately turned out to be a blocker on getting WASI support as there's not direct threading support in WebAssembly."
But due to the leadership/community model/aversion to big changes (except for alienating people with 2 to 3 changes) none of this was in the context of CPython, they were independent versions, that never caught on, and didn't leave anything (or much) behind to the regular CPython when they folded.
I would argue the opposite: it's the secret to Python's success. It might even be my top example of how "worse is better" plays out in real life.
I agree, the GIL feels like an ugly hack. The software engineer in me wants to hate it so much. And, now that I'm on the far side of a successful transition to a data science role, one might think that I hate it even more, yeah? Because the work I'm doing depends so very heavily on compute performance and parallelism.
But it turns out, nah, I'm coming to like it. It's an ugly hack, but it's the best kind of ugly hack: one that gets the job done.
Because I'm pretty sure that the GIL is the secret sauce that makes Python C extensions work so well. Without it, it would be much more difficult to write safe, correct C extensions. Doing it without introducing race conditions that destroy memory safety would be a black art. So people would probably do it less. And that probably means no robust Python scientific computing or data science ecosystem, because that stuff is all C extensions.
We could instead use a C FFI, like it's done in other languages. Java, for example. But Java having to use an FFI and Python being able to use its C extension mechanism is exactly why Python has eaten all of Java's Wheaties in the data space. The marshaling costs of talking back and forth across that boundary are just too high. Copying goes up, locality of reference goes down, cache misses go up. You saturate the memory bus more quickly. Once you've done that, it doesn't matter how many threads you have running on how many cores. The bottleneck is happening outside the CPU. Top will happily tell you those cores are working hard, but it turns out that what they're working so hard at is sitting around and waiting.
This isn't just theoretical. Last year I replaced a heavily parallelized compute-heavy batch process written in Java with a Python implementation that got the work done in less time despite being single-threaded. Sure, the Python implementation was basically a little scripting on top of a library written in C++, and the Java one was pure Java. But that's kind of the whole point. I also know that, back when I wrote the original Java implementation, I tried the same trick of farming the calculation out to a C++ library, and it actually made the throughput even worse. JNI is a harsh master.
And besides, as others have said, numpy & friends give me most the parallelism I actually need, for free.
Maybe it hurts other people more? Maybe Web developers? But there's a part of me that thinks, if you're trying to do that kind of work at scale, making Python go faster is perhaps barking up the wrong tree. There are plenty of other languages that are statically typed (reducing pointer chasing and branching can increase your throughput without giving Amazon more money in the process) and don't even need a global interpreter lock in the first place because they're not interpreted, either.
I am not sure about it. Python explicitly trades performance for simplicity and the GIL simplifies a whole lot of things and because of it, there are multi threading issues that will never be encountered by Python code.
In addition, because of Python’s popularity, there is a massive amount of code written in Python (and other languages as extensions) and any change cannot introduce a bug.
Finally, there are other alternatives to Python that are more performance focused.
If you are having huge issues with Python performance, maybe you are using it in a matter it was not designed for.
That's not a noob question. That's a loaded question, from a perspective of knowing what people use Python for.
People use Python for all kinds of things, and a lot of them would be faster if they were able to take advantage of multithreading without the GIL.
Well, if they didn't, we'd still be stuck with Python 1 or 0.1.
Why is the GIL suddenly where Python should keep "being what it is", and not any of those tons of changes, from 0.1 to 3.10?
Especially since the removal of the GIL doesn't change any spirit/essence of Python - just makes it faster.
Python wasn't conceived as "having a GIL" being some essential part of it, it was just a bad tradeoff for implementation convenience made back in the day where common multi-core machines were 20 years in the future...
[1]https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsD...
> Why need concurrency in normal python scripts let’s days for web scraping or machine learning ?
I had a few scripts where I had to process over a hundred files, just running that in parallel can reduce a job that takes minutes to seconds.
From your link:
"Stripping out some of the GIL-removal related changes would result in even faster performance on the single-threaded pyperformance benchmark suite. [...] The resulting interpreter is about 9% faster than the no-GIL proof-of-concept (or ~19% faster than CPython 3.9.0a3). That 9% difference between the “nogil” interpreter and the stripped-down “nogil” interpreter can be thought of as the “cost” of the major GIL-removal changes."
So it seems removing the GIL has a negative impact on single-threaded code, with the version that has both the GIL and the unrelated optimizations being 9% faster.
They are trying to strengthen corporate influence and discourage any power of traditional independent open source developers (who have contributed most of the useful features as opposed to corporate churn).
We do not know what is going on in the background, it is proxy wars all over the place. It is possible that they want to reduce Facebook influence, that their code bases do not need this feature, etc.
Just use C++.
One of the saddest things about popular open-source projects like Python is how inevitably the maintainers become worn down and jaded over time, due to constantly filtering and protecting Python from dumb or nonsensical ideas.
Then when something like this comes along, a true game changer, maintainers have no energy or goodwill left to collaborate on these infinitely important initiatives, like removing the dogdamn GIL. This is way more significant than everything I'm aware of that's happened since the birth of the language. All other things have been, trivial miuntiae in comparison.
It bears repeating: "everything else has been trivial minutiae in comparison to a GIL-ectamy for Python."
It cannot be understated, removing the GIL will be a HUGE deal for Python! It's an ugly wart which has existed for about 30 years, and nobody else has produced and delivered a working solution to the community.
I wish Team Python would welcome GIL Eradication with open arms and a supportive attitude. This would look like focusing on helping identify and implement solutions to the impediments rather than simply pointing out problems and then helicoptering away.