Hacker News Reader

Removing the GIL will also make some currently-correct threaded code into incorrect code, since the GIL gives some convenient default safety that I keep seeing people accidentally rely on without knowing it exists.

Unavoidable performance costs and reduced safety equals massive friction no matter how it's approached. It's not a question of "are we smart enough to make this better in every way", since the answer is "no, and nobody can be, because it can't be done". It's only "will we make this divisive change".

To think about it, perhaps US should have started metrification back in 1980 when EU enforced it for its members. It takes time, but is doable - if took Ireland 25 years to fully switch to metric.

The cost of switching increases over time and will increase further and further, making it less and less likely. Would have been way cheaper back then.

> To think about it, perhaps US should have started metrification back in 1980

The US started that in either 1875 or 1893, though, and somewhat more aggressively in 1975.

It reversed course in the 1980s, it didn't fail to start before that.

There were already patches to "just" remove the GIL for Python 2.0 or thereabouts, over 20 years ago. Strictly technically speaking it's not even that hard, but as you mentioned it comes with all sorts of trade-offs.

Today Python is one of the world's most popular programming language, if not the most popular language. The GIL is limiting and a trade-off in itself of course – designing any programming language is an exercise in trade-offs. But clearly Python has gotten quite far with the set of trade-offs it has chosen: you need to be careful to "just" radically change the set of trade-offs that have proven themselves to be quite successful.

You should check out the new nogil project by Sam Gross, which is what's being talked about these days -- he actually successfully removed the gil, but yes with the tradeoffs that you mention. The other projects were, by comparison, "attempts" to remove the gil, and didn't address core issues such as ownership races (which are far harder than making refcount operations atomic).

I indirectly referenced it. IIRC the main problems with his approach are the ABI problem and the mutex overhead. He tries to "solve" the performance hit by offsetting with performance gains elsewhere, but that raises the question "why not take the gains by themselves".

> That just is doing an incredible amount of heavy lifting. It'd be like saying, "Why doesn't the USA just switch entirely to the metric system?" It's a huge ask, and after being burned by the 2/3 transition, the python team is loathe to rock to boat too much again.

> The GIL is deep, arguably one of the deepest abstractions in the codebase, up there with PyObject itself. Think about having to redefine the String implementation of a codebase in your language of choice.

I am somewhat familiar with the cpython code base, and talk to some folks involves in some of thousand new python runtime.

The problem is not that deep, and cpython is not that much different from other projects : the GIL is an implementation details that leaked through the API and now we have a bunch of people are relying on it. The question is what do we do about it. The trade-off in such situation are well known and just a question to pick the right one.

> The team has already decided those tradeoffs are not really justifiable.

That's from my view the crust of the issue, the TLDR is that GIL-less python is not a priority for the python team, so they view any trade-off/comprise as "not justifiable". Especially something when it come to added complexity to the code base or what not...

> Person with limited to zero experience with CPython internals> I hate the GIL, why don't they just remove it?

People have this reaction because having a single-threaded interpreter in 2023 is just ... embarrassing, what ever the reasons behind it.

It only takes a couple of minutes to educate yourself on this topic. After reading it, let me know if you still think they don't want to compromise.

https://www.artima.com/weblogs/viewpost.jsp?thread=214235

> It only takes a couple of minutes to educate yourself on this topic.

You can disagree without assuming that i am not familiar with the subject.

The link you provided is from 2007 so i am not sure how fair it is to quote guido from then. But i am not sure the link demonstrate the point you are trying to make, from guido himself :

> While it is my personal opinion, based upon the above considerations, that there isn't enough value in removing the GIL to warrant the effort.

Edit : If you want a newer reference, this HN threads and the links discribe the situation well https://news.ycombinator.com/item?id=36240998

Which is the point i am making... This is not really a technical issue, the python just doesn't think it's worth the effort.

> From a steering council perspective we effectively view a 703 threading enabled interpreter at a high level as a fork of the CPython VM.

"Fork" and "effort" are different problems. It's reductive to say that effort alone is the tldr.

If the 2007 article and the linked current FAQ seem too old to be relevant, you're not really understanding what the steering committee is saying today.

> "Fork" and "effort" are different problems. It's reductive to say that effort alone is the tldr.

It's very unclear what you mean here, what does that have to do with the problem. Pep 703 is not a fork of CPython.

Sam had (very highly impressive) protype of a gil-less cpython. It clearly demonstrate the feasibility and viability of nogil. It can be a drop in replacement, with the disabled/enable-gil option.

Pep 703 is about integrating it into the main cpython codebase...

> If the 2007 article and the linked current FAQ seem too old to be relevant

I never said that the age of the article make irrelevant . What i said is that a lot of things change in 18 years, and it might not represent the current thinking of the person today. So i was trying to charitable to guido perspective. But in the article (from 2007) that linked it's clear that from his perspective the time/effort investment is not worth the pay out.

> you're not really understanding what the steering committee is saying today. > It only takes a couple of minutes to educate yourself on this topic

You keep insinuating that my current view on the situation is rooted in some kind of ignorance or some kind of misunderstanding. But you still haven't really made clear and cogent arguments for your point of view...

GVR called it a fork two weeks ago in his justification for not accepting it [1]. If that surprises you, the backstory is summarized pretty well in the article [2] and FAQ [3].

I'm really not trying to be secretive. We can debate whatever you want, but we have to at least acknowledge CPython's stated position.

[1] https://github.com/python/steering-council/issues/188#issuec...

[2] https://www.artima.com/weblogs/viewpost.jsp?thread=214235

[3] https://docs.python.org/3/faq/library.html#can-t-we-get-rid-...

> but we have to at least acknowledge CPython's stated position.

We know the council and cpython stated position. None of the arguments in [1],[2] or [3] are new... The point is we disagree with it...

You seem to imply that because GVR and/or the council call it a fork, then it is a fork... Again, we understand the position, we just think is not a valid point...

> We can debate whatever you want

You haven't debated anything yet... you just repeat/link what member of the council says and somehow call that an argument... This is very confusing

The usual way to dispute a decision is to start by refuting the justification. I think that's a reasonable ask.

It was never my intention to dispute the council decision (choice really). One can disagree with a decision without needing to dispute it. Concerning the justifications, here again i am a bit confused, because all references you are giving, point to the amount of effort as being one (if not the biggest) concerns... which the what i am saying.

But to take a step back, my main point was about the OP who described the situation as some cancer-cure level of complexity, comparing it to moving 300 million people from the imperial system to the metric system... : And i am saying that the situation here is not that complicated all the technical problem s can be address "at the same time" , but at the price a very large dev. effort and increase in complexity of the code base. The council doesn't think that gil-less is worth that amount of trouble.

Completely agree with you about it not being technically complex.

I responded to your other comment, so let's move it over there.

703 is probably the right path towards true gilless python, but to quote Greg Smith (gpshead) on the PR,

> We're not ready to simply pronounce on 703 as it has a HUGE blast radius.

703 isn't even out of draft PEP status. I think they need to come to consensus on 703, or modify it until it is acceptable, and then figure out how to merge the code and release it.

I don't know for sure, but it looks like even with the compile nogil flag off, there are enough low-level API changes that extensions would break. If they can do it without breaking extensions with the flag off, I can see this happening over the next few years. But it's no small feat.

I don't think anybody is saying to accept PEP 703 (and i don't want to make this conversation just about PEP 703, there was many other promising gil-less proposals) tomorrow.

The main complain of the author of PEP (and other people as well) is the lack of clarity on the criteria for inclusion, as well as the constant goal post moving.

> it looks like even with the compile nogil flag off, there are enough low-level API changes that extensions would break.

From my understand, after testing from the author (and couple of other people on the discord thread) no case have been found yet. Greg's point is that the blast radium is so large that there is high probability that this might happen. We won't know until we test in the wild... And we won't test in the wild until the council arrives at a conclusion.

The burden of proof here is so absurdly high, and has to be paid be Sam alone here that this will essentially kill this proposal.

> the lack of clarity on the criteria for inclusion, as well as the constant goal post moving

This is where I think Sam is being unfair. He's asking for a breaking change. For 25 years, CPython has consistently and clearly said that they fully support no-gil in other implementations, and have a minimum criteria of no performance regressions for CPython. He made his performance demonstration before getting real buy-in. I understand he made that choice because of how his funding works, and now he's desperate to get a result. They acknowledged his demo and said they're considering it. Lashing out and accusing them of unclear criteria and moving goalposts misrepresents the situation.

It's not his decision to risk burning the community on a breaking change. He knows they haven't decided on it. It's reasonable to expect someone to do that work. He hasn't done it, so they will have to do it.

The steering committee also has to consider how this change will impact pursuing other goals. It doesn't exist in a vacuum all by itself.

They reiterated that they do in fact want to remove the gil, even after noting how much work it will be to do due diligence. They've also said they want to take in big projects like creating a JIT. Seems to me like effort itself isn't an issue. By calling it a fork, coming from the steering committee, they're saying either the transition plan is non-existent, or it's the wrong design for their goals, or it's coming at a bad time. Maybe all of them.

His task was to convince the committee to remove the gil. He interpreted that as simply doing a technical demonstration. Not sure why, especially given the history.

It's partly political. If GvR is paid by a company to work on something, the result goes in, no matter how bad it is.

The NoGIL effort comes from Facebook and as such is suspect (until Microsoft switches to Golang like Google and Dropbox and GvR moves to Facebook).

> The problem is not that deep

Technically yes, the data structure can be abstracted over and removed, in that sense, it isn't "deep". But the reason I say it's deep is because of the deep implications and assumptions of the GIL being there. For decades, the codebase (and extensions) has grown with the expectation that the GIL enforces a certain behavior.

> That's from my view the crust of the issue, the TLDR is that GIL-less python is not a priority for the python team, so they view any trade-off/comprise as "not justifiable". Especially something when it come to added complexity to the code base or what not...

Precisely. Because it's such a hard problem. If someone had a proposal to actually remove the GIL, limit the single core performance hit to say <10%, and not break extensions, I have no doubt the steering team would go for it. It would be huge PR for python, simply because of the Gil's bad rap.

Turns out that multi-interpreters give you most of the benefit of multithreading with nowhere near as much complexity.

> People have this reaction because having a single-threaded interpreter in 2023 is just ... embarrassing, what ever the reasons behind it.

What other dynamic languages invented over 3 decade ago have natively multithreaded interpreters? Oh javascript, the (fundamentally simpler on a technical level and uses different gc techniques) language which has gotten millions of dollars in development by the biggest tech companies because it runs on nearly every browser and thus has huge incentives to optimize? If python ran in every browser, the Gil would be gone by now.

Java? Again, huge amount of backing, 15 years older than python.

Perl, ruby, lua, all use refcount and have single-threaded interpreters. Objective C might fit the bill for multithreaded refcount gc (I don't know, I'm asking gpt). Nim does, but it's rather modern, (2008). Swift is statically typed, which helps, and much newer (2014).

I guess that leaves Erlang, which again uses different gc techniques.

I guess the takeaway is refcount is probably not the best design choice for writing a modern dynamic language if you value multithreading.

> But the reason I say it's deep is because of the deep implications and assumptions of the GIL being there. For decades, the codebase (and extensions) has grown with the expectation that the GIL enforces a certain behavior.

As i mentioned... The idea of keeping backward compact. of an implementation details which leaked into the API is kinda common. Some of the current proposal are about making the gil optional, keeping the compact for those cases...

> Precisely. Because it's such a hard problem. If someone had a proposal to actually remove the GIL, limit the single core performance hit to say <10%, and not break extensions, I have no doubt the steering team would go for it. It would be huge PR for python, simply because of the Gil's bad rap.

I think this might be were we disagree the most. One doesn't sit around, put a collection of constraints into the ether and expect a solution to magically appear... Obviously every one wants a perfect solution to technical problems, but those don't really exists.

The true measure of the willingness of the council to accept gil is about the compromises they are willing to make to accept external solutions or the effort put into developing their own solutions.

Even if the council just had put some effort into developing a suits of test cases (both performance and correctness), or try to pull some statistical information on how many C extensions rely on the gil for correct behavior, how hard would a transition for those be? can we leverage runtime tooling like valgrind and/or llvm (thread|memory)sanitizer to detect some and ease the transition.

But i haven't seen any real effort, just the same list of constraints we had the last 10 years.

> Turns out that multi-interpreters give you most of the benefit of multithreading with nowhere near as much complexity.

I am only tangentially familiar with the sub interpreter proposal, but what i understand, i disagree. This the classic sharing memory vs message passing trade-off...

Also not to forget that this does might still break C-extension which sometime relies on static variable (like the comment from the author or mysql extension mentioned).

But i don't want to make this about this or that specific proposal. if the council prefer sub interpreter approach to nogil, they should say so and don't have people waste their time.

> What other dynamic languages invented over 3 decade ago have natively multithreaded interpreters? Oh javascript, the (fundamentally simpler on a technical level and uses different gc techniques) language which has gotten millions of dollars in development by the biggest tech companies because it runs on nearly every browser and thus has huge incentives to optimize? If python ran in every browser, the Gil would be gone by now. > Java? Again, huge amount of backing, 15 years older than python. > Perl, ruby, lua, all use refcount and have single-threaded interpreters. Objective C might fit the bill for multithreaded refcount gc (I don't know, I'm asking gpt). Nim does, but it's rather modern, (2008). Swift is statically typed, which helps, and much newer (2014).

I don't want to sound to harsh, but you go to war with the army you have, not the army you want. The question is not what the optimal solution would look like if we had optimal conditions (deeper pockets, gc vs refc, etc... etc...). Python is what python is, the python organization have the resources that they have. No doubt we could design a better solution with more money or a with a language with better semantic, but don't have neither and that shouldn't prevent the council of acting on the best solution we have right now...