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

311–320 of 513 posts

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

#311

Post by Dylan16807 »

lozenge wrote: post #300
miraculixx wrote: post #263

Earlier quoted context omitted.

Here's what's puzzling me about this: Why then is there even a need for a seperate nogil build? If it is like this says, wouldn't it be easier to just make the standard build switch to gil or nogil automatically (or honor the users choice). The fact that the SC thinks having two versions suggests there is more complexity involved than this section of the PEP leads readers to believe.

You have to recompile your C extensions for the nogil build. Consider an application where one thread is calling xs.append from a C extension and another is calling xs.pop and xs[-1] on the same list object xs. In the nogil build these operations need to use a fine-grained lock on xs, and in the gil build these are thread-safe due to each thread holding the GIL when it does these operations. On top of that, some of t…

> However, it looks like the nogil build will be able to run in "GIL mode" for maximum compatibility, including switching to GIL mode partway through execution

Yes, that's what they were asking about. Why have two versions for a mode switch. Everything you explained before that is irrelevant, I'm afraid.

> but I'm expecting this to be slower than running the gil build in GIL mode.

That could be the answer to their question, but that's not definitive enough.

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

#312

Post by gjulianm »

winter_blue wrote: post #102
ggm wrote: post #33

Lots of C library code for decades carried man page warnings it was unstable for use in async, re-entrant and recursive contexts. We learned how to cope and incrementally re-entrant safe versions deployed without too much API instability. Maybe time has healed wounds and caused me memory loss of the pain of discovery you'd tripped over them. String parsing which tokenised in-place. DNS calls which used static buffers…

I wonder why so many library developers even chose to build native libraries on the shaky and poorly-architected foundation that Python is. Even writing a JVM native JNI library would have allowed to avoid a lot of that pain (and the library would have been useable from Clojure, Kotlin , Scala, JRuby[1], Jython[2], Java, etc) without any painful threading issues. [1] which I’m aware of having been used in production…

I think there are several reasons:

- The history is backwards: it isn’t that devs wanted to make a native library and then chose Python, it’s that they chose Python and then they needed a native library.

- Python works very well for scripts and small programs, and decently well for medium-size programs. This makes libraries with concrete purposes very useful and productive. If your library, say, helps devs do some basic calculation with time series, the ability to be used in quick scripts is a big plus.

- The C API is fairly good, and libraries such as pybind11 make it even better. You don’t need a lot of code or boilerplate for an extension.

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

#313

Post by lozenge »

toyg wrote: post #288
gary_0 wrote: post #211

Earlier quoted context omitted.

They say they want no-gil to be the only build mode 5 years from when it becomes available. That is both too long and too short. That is too long for Python to have 2 modes. Half a decade is more than enough time for 2 modes to become the status quo. For one thing, think of all the outdated Stackoverflow threads that will be hanging around after that 5 years. I am not optimistic that 5 years won't turn into 10 years…

> 5 years might be too short for everyone to dredge up all that C code, update it, test it, and call it mature. Developers are lazy. Most people will just do nothing until, 5 years from now, some blog post will go "oh, next month we switch noGil as default, good luck!". At that point everyone will scramble, rush out buggy releases, and spend 5 years finding all the problems.

The no-gil "build mode" will still have the ability to switch to GIL "run mode", it will just be slower than the GIL run mode on the GIL build mode. Hopefully not much slower.

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

#314

Post by lozenge »

jborean93 wrote: post #254
a_nop wrote: post #104

Earlier quoted context omitted.

They kind of burned a breaking major version transition for no good reason with 2-to-3, now they are prefacing a major change with "it won't be like 2-to-3". It sounds like they may be maintaining two operating modes in CPython 3 instead of going forward with another major transition, just because of that history.

> They kind of burned a breaking major version transition for no good reason with 2-to-3 The unicode/text changes alone were a pretty good reason. Division producing floats are also a nice change IMO. I don’t want to discount the challenges with the transition but saying there was no good reason isn’t right to me.

There were a lot of bad reasons as well. The removal of the u string prefix in versions 3.0-3.2 was unnecessary and made the transition much more difficult. It kind of gave Python 3 a bad reputation.

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

#315

Post by miraculixx »

dgb23 wrote: post #275
hanselot wrote: post #247

Earlier quoted context omitted.

Sometimes the right thing is writing code in a language that reaches market before runway runs out.

Ecosystem churn and exposing more issues to python contradicts this. The whole point of using languages like python, js etc. is to not worry about whole classes of problems and intricacies. There are modern languages with great tooling like Go, Rust or Clojure that have excellent support for safe concurrency and parallel execution etc. And there are reliable, well established languages like Java/C# that have been doi…

This. Python had a unique stance, it was different for a good reason.

The seamingly endless attempt to become more likeable to yet another subgroup of needs is not a good development. It started with static typing, it continued with async, and now we have free threading as the final draw.

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

#316

Post by Dylan16807 »

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.

"it supports both. Done." is not how Python 2/3 went. You have no idea what you're talking about.

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

#317

Post by usrbinbash »

miraculixx wrote: post #307
usrbinbash wrote: post #264

Earlier quoted context omitted.

First of all, these changes are not being introduced because of a committee. They are being introduced because a way to get true thread-based parallelism in Python has been one of THE top priority demands of a huge part of the Python developer community for ages. > “but now I have to rewrite my library because some people might use it in non-GIL mode”. Yes, if library maintainers want their library to remain relevant…

> They are being introduced because a way to get true thread-based parallelism in Python has been one of THE top priority demands of a huge part of the Python Where is this demand exactly? We hear a lot of complaining but very often this is due to a lack of awareness of available (& often better) alternatives to threading. There is a very small number of use cases that will benefit from free threading.

> Where is this demand exactly?

The motivation summary of PEP-703 contains some material on this:

https://peps.python.org/pep-0703/#motivation

Further discussions going back years can be found with a brief search. This discussion is almost as old as Python3.

> due to a lack of awareness of available (& often better) alternatives to threading.

Such as?

There are exactly 2: asyncio, which is useless for CPU/GPU bound workloads, and multiprocessing with all the pain of relying on expensive spawns, expensive and limited IPC and the joy of having to orchestrate across process boundaries.

Guess what the most common advice is for dealing with CPU bound parallelisation problems in Python? "Use another language". Guess what all the languages recommended (C, C++, Rust, Go, Java) have in common? They have thread-based parallelism.

> There is a very small number of use cases that will benefit from free threading.

Basically any workload that is CPU bound, which in the day and age of giant data aggragation and running huge ML models at scale is more important than every before, is a use case for this.

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

#318

Post by miraculixx »

tjpnz wrote: post #229
KeplerBoy wrote: post #227

Earlier quoted context omitted.

Even with multithreading Python will still be slow. It's not like singlethreaded Python can keep up with singlethreaded C or even JS. This will just allow people to waste even more compute resources to get somewhat quick results from Python instead of doing the right thing. From an ecological viewpoint this PEP will be disastrous and keep entire power plants online.

The text editors people use to write said code will keep even more power plants online.

Especially PyCharm with its endless indexing. Have the time its key features are not available bc it has decided to go on another indexing spree. Alas that's for another thread ;)

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

#319

Post by MrStonedOne »

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…

[dead]

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

#320

Post by samus »

weinzierl wrote: post #293
neilv wrote: post #61

Earlier quoted context omitted.

I remember scouring those C runtime docs, for every non-reentrant function. It might be what got me in the habit of checking docs when using some API that I know moderately well, just in case there's some important detail I missed before, or something had changed. Around that time, doing cross-platform C++, I got an early look at Java, with concurrency built in from the start, along with GC and various other nice fea…

That Java had concurrency built in from the start is a blessing mostly, but also a bit of a curse. Most of the Java ecosystem is still in the mindset that threads are cheap and firing up a couple more cannot hurt. So we end up with apps that run thousands of threads and this disease is hard to contain.

Fortunately Virtual Threads have landed, so when the ecosystem finally comes around to adopt it, many things might become faster.
Post reply on HN