Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intent to approve PEP 703: making the GIL optional

discuss.python.org

Post reply on HN
Print view View original

161–170 of 513 posts

Re: Intent to approve PEP 703: making the GIL optional

#161

Post by wokwokwok »

qbasic_forever wrote: post #157
wokwokwok wrote: post #153

Earlier quoted context omitted.

You can down vote this til the cows come home but it’s historically what happened. This “that’s not how it went” stuff going down is quite just blatant historical revisionism. Maybe it’s a good idea? Maybe it’s not? …but anyone down voting “this reminds me of the Python 2/3” fiasco has no idea what they’re talking about.

It's good if there's a benefit for everyone, like python 3 fixing the terrible Unicode story. It's not clear non-GIL will even be a net performance improvement for most people--you are effectively moving syncronization from the core runtime to each and every library and program at the edge. Writing safe code at that level doesn't come for free, your basic program will be slower (and likely buggier) if every call into…

I’m not gonna argue that point; but it seems massively disingenuous to down vote someone who complains “but now I have to rewrite my library because some people might use it in non-GIL mode”.

That’s not whining; it’s just an observation that the committee making these decisions gives zero ducks about the impact this will have for anyone other than the handful of vested parties involved in making the decisions.

Pypi has what, 500k projects on it? Many abandoned.

Whom exactly is going to update those?

Or do packages get an automatic “doesn’t work with no-GIL” unless the author explicitly opts to enable it?

Or do we live in a future where any package, with any dependency may or may not have undefined behaviour in no-GIL mode?

Like, sure… it’s a good change for many people… once all the hard work is done by the community.

Does that remind you of anything?

Mmm.

Re: Intent to approve PEP 703: making the GIL optional

#162

Post by soulbadguy »

dboreham wrote: post #155
eru wrote: post #105

Earlier quoted context omitted.

> I got an early look at Java, with concurrency built in from the start, [...] and I "knew" it was going to be huge. And Java doesn't even have good (conceptual) support for concurrency. Compared with eg Erlang, Rust or even Haskell. But Java was still better at it than C or C++ at the time.

In your opinion. Some of us believe the exact opposite.

There are a lot of good things about java (and the jvm by some extend), but good concurency is not one of them.

Re: Intent to approve PEP 703: making the GIL optional

#163

Post by slt2021 »

opportune wrote: post #149
slt2021 wrote: post #54

Naiive question: Who needs No-GIL when we have asyncio and multiprocessing packages ? never ever had a problem with GIL in python, always found a workaround just by spinning up ThreadPool or ProcessPool, and used async libraries when needed. is there any use case of No-GIL which is not solved by multiprocessing ? I thought Single threaded execution without overhead for concurrency primitives is the best way to high p…

The problem with only relying on asyncio and multiprocessing is that they only implement per-process concurrency and parallelization per-process. Threads let you use the same unified abstraction for parallelization and concurrency. They also make it easier to share state with parallelization (no need to go out of your way to do it) at the cost of requiring you to think about and implement thread safety when you do so…

multithreading with shared state introduces several limitations:

  1. random jumps in memory and branch misses
  2. L1/L2 cache flush
  3. context switch cost
  4. concurrency locks cost
my understanding is that LMAX eliminated these costs:

  1. pre-allocated arena ensures cache locality of operations
  2. we dont jump form one sector of memory into another. Algorithm more resembles linear scanning of working memory set, and mostly within L1/L2 cache
  3. no context switches, no cache flushes
  4. no concurrency control costs

Re: Intent to approve PEP 703: making the GIL optional

#164

Post by ctoth »

wokwokwok wrote: post #153
qbasic_forever wrote: post #132

Earlier quoted context omitted.

You're saying, "just rewrite and re-release all your dependencies, it's easy!" which was exactly what happened disastrously with python 2 to 3.

You can down vote this til the cows come home but it’s historically what happened. This “that’s not how it went” stuff going down is quite just blatant historical revisionism. Maybe it’s a good idea? Maybe it’s not? …but anyone down voting “this reminds me of the Python 2/3” fiasco has no idea what they’re talking about.

Except they're not at all analogous situations. In python 2 -> 3, if a new version of a library came out Python 3 only, you couldn't use both it, and your old Python 2 code at the same time. Here, you can use the GIL until every one of your dependencies have migrated, even as new versions of your dependencies come out with nogil support until one magical day they all have nogil and you can migrate. But since you have been able to keep up with the library and weren't just arbitrarily cut off at their last Python2/GIL version, it's not a huge breaking change!

Re: Intent to approve PEP 703: making the GIL optional

#165

Post by asvitkine »

n2d4 wrote: post #25
miraculixx wrote: post #16

Unpopular opinion: This is a missed opportunity. What? Python could have been the one language with a sane multithreading model. Now it risks becoming a second version of Java. I fear this will make it a less attractive programming language, not least because it might lose its beginner friendlyness. For example, without the GIL a lot more care must be put into designing your programs. This can be true even though you…

The GIL does very little to protect unexperienced users. It's still really easy to run into race conditions, for example, if your thread gets scheduled out in any multi-instruction operation (this is more common than you think [1]). In general, Python code still has to be thread-safe; you get the risks without the benefits. If you don't care about CPU performance, instead of threads you should go for an event-loop ap…

I don't think the blog you cite backs up your claim of "it's still really easy to run into race conditions".

The author literally says: "This was actually pretty hard to discover. The first few experiments failed, because Python is pretty smart about when it runs each thread."

But I think the main way the GIL protects inexperienced users is that its presence has the effect that Python code using the threading APIs is very uncommon, since those APIs don't currently provide parallel computation (only parallel IO). So inexperienced users are protected due to 99% of Python programs not using multithreading as a result (and so likely the one they're developing also doesn't), whereas this will presumably change when the limitations imposed by the GIL go away.

Re: Intent to approve PEP 703: making the GIL optional

#166

Post by paulddraper »

nequo wrote: post #141
paulddraper wrote: post #124

Earlier quoted context omitted.

As sibling comments says, GIL mode can run no-GIL code. Entirely different from 2->3. That analogy is so poorly applicable it's laughable.

Without the last sentence, your comment would be better.

It's not nice but it is true.

"Dur dur this is just like 2 -> 3."

HN had always been susceptible to drive-by ignorant comments, but it's reaching new levels.

There's literally nothing of substance to the suggestion. (And if you think there is, present an actual informed argument.)

Re: Intent to approve PEP 703: making the GIL optional

#167

Post by eru »

dboreham wrote: post #155
eru wrote: post #105

Earlier quoted context omitted.

> I got an early look at Java, with concurrency built in from the start, [...] and I "knew" it was going to be huge. And Java doesn't even have good (conceptual) support for concurrency. Compared with eg Erlang, Rust or even Haskell. But Java was still better at it than C or C++ at the time.

In your opinion. Some of us believe the exact opposite.

By exact opposite you mean that when Java just came out ('I got an early look at Java, [...]') had good concurrency support?

One can make a solid argument that modern Java is adequate. But I don't buy you believe that of early Java?

Re: Intent to approve PEP 703: making the GIL optional

#168

Post by TylerE »

qbasic_forever wrote: post #137
MarkMarine wrote: post #128

Earlier quoted context omitted.

I’m no fan of Java, but in comparison with python, Java’s focus on extreme backwards compatibility and their ability to actually execute on this promise year after year stands in stark relief with how python has handled the same challenges. I have low confidence, despite their claims this won’t be python 4, that this will actually be executed well. Looking forward to having homebrew deliver python@3.25_GIL and python…

Yep, and you'll have pip3-gil and pip3-nogil binaries because each permutation of python has separate and incompatible site-packages folders and libraries. It could get really ugly.

Is the situation in rust, where the answer is apparently to vendor the world, much better? Don't many of the big rust libraries still depend on nightly, too?

Re: Intent to approve PEP 703: making the GIL optional

#169

Post by dingi »

miraculixx wrote: post #16

Unpopular opinion: This is a missed opportunity. What? Python could have been the one language with a sane multithreading model. Now it risks becoming a second version of Java. I fear this will make it a less attractive programming language, not least because it might lose its beginner friendlyness. For example, without the GIL a lot more care must be put into designing your programs. This can be true even though you…

I’m genuinely curious, What's wrong with Java's model?

Re: Intent to approve PEP 703: making the GIL optional

#170

Post by qbasic_forever »

wokwokwok wrote: post #161
qbasic_forever wrote: post #157

Earlier quoted context omitted.

It's good if there's a benefit for everyone, like python 3 fixing the terrible Unicode story. It's not clear non-GIL will even be a net performance improvement for most people--you are effectively moving syncronization from the core runtime to each and every library and program at the edge. Writing safe code at that level doesn't come for free, your basic program will be slower (and likely buggier) if every call into…

I’m not gonna argue that point; but it seems massively disingenuous to down vote someone who complains “but now I have to rewrite my library because some people might use it in non-GIL mode”. That’s not whining; it’s just an observation that the committee making these decisions gives zero ducks about the impact this will have for anyone other than the handful of vested parties involved in making the decisions. Pypi h…

Yep I fully agree. It's going to ultimately mean 99% of people end up running in old GIL mode with deterministic behavior. Companies will get burned and have to have policies that absolutely under no circumstances will the GIL be disabled in their codebase. A very small handful of highly skilled and funded teams, probably at big companies only, will have the time and tenacity to make their code AND all their dependencies work in a multithreaded environment without the GIL.
Post reply on HN