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

411–420 of 513 posts

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

#411

Post by pritambaral »

School-Cotton wrote: post #404
usrbinbash wrote: post #317

Earlier quoted context omitted.

> 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 w…

> Use another language Right, because the whole point of Python is as a glue language for native libraries. Adding multi threading to Python is like adding to to Bash.

> Right, because the whole point of Python is as a glue language for native libraries.

I have had this precise need before. I have a multi-threaded native library. The multi-threading is essential for reasonable performance in the intended use-case for the library. But my users can't write C++ to call it; they'd like Python. They'd like to extend certain specific operations that my native library does during processing. I give them Python bindings. The perf gained by running the library on multiple cores is completely negated whenever multiple C++ threads of my native library need to run Python code.

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

#412

Post by andybak »

t-vi wrote: post #407
andybak wrote: post #378

Earlier quoted context omitted.

When I learned Python decades or so ago virtualenvs were standard practice. Who is using system level Python for anything non-trivial?

I use Debian's system Python 3.10 install for most of my stuff and it works really well for me. Some things I install via pip but the key libraries (e.g. PyTorch) from source.

Don't you ever have projects with conflicting requirements? How about running stuff on a new box or after a reinstall?

I wonder if our definition of "non-trivial" might differ if neither of these apply.

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

#413

Post by pritambaral »

HoppyHaus wrote: post #198
mikepurvis wrote: post #195

Earlier quoted context omitted.

Coming from a place of total ignorance, it would be nice if you could do this more incrementally, like have it be in no-gil mode by default, but then have a context manager you can use for gil sections, and have the interpreter bomb out if you try to enter gil-required code while still in no-gil mode.

The issue is when someone's unattended-upgrades bumps up the version and causes something to come crashing down. The people who need to use nogil should know that they need to, and will now have the ability to enable it

> ... unattended-upgrades bumps up the version

Surely, unattended-upgrades should NOT be bumping major versions?

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

#414

Post by insanitybit »

Dylan16807 wrote: post #338
majewsky wrote: post #328

Earlier quoted context omitted.

They were suggesting that this is a question that is going to be on people's minds, which is very different from suggesting that the answer is yes.

All I can say is that the phrasing looks quite biased to me and it would have been easy to not phrase it that way. Subtext is hard to prove, but that doesn't make it not real.

It seems to have clearly been a case of "I remember 2 to 3, that was really bad. I imagine everyone else is wondering this - is this going to be another 2 to 3?"

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

#415

Post by pritambaral »

MrYellowP wrote: post #177

I'm going to miss the thread-safety non-GIL python offered. That being said, this is interesting. Can we get an in-python fork() mechanic ... please?

> I'm going to miss the thread-safety non-GIL python offered.

The old method — which is the GIL, or non-non-GIL — provides no thread safety to Python code. It only protects C code

> Can we get an in-python fork() mechanic ... please?

You probably want Multiple Subinterpreters: https://github.com/python/cpython/issues/84692

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

#416

Post by csmpltn »

usrbinbash wrote: post #366
miraculixx wrote: post #329

Earlier quoted context omitted.

> The GIL doesn't prevent race conditions between individual python instructions Yes it does. Unless we mean something different?

> Yes it does. No, it doesn't. def thread_function(): # thread may lose core here value = store.get_value() # or anywhere inside get_value # or here update(value) # or anywhere inside update() # or here store.put_value(value) # or anywhere inside put_value() The GIL only makes certain internal functionality atomic. It doesn't protect the implemented logic from causing a race condition. So unless I protect store with…

The user you're replying to is saying that the GIL is preventing multiple threads from executing Python bytecodes at once (preventing some classes of race conditions and ensuring thread safety). They are absolutely correct.

The GIL doesn't solve or prevent all classes of race conditions (which can stem from complex interactions with databases, the filesystem, etc). Removing the GIL though, will only make things worse from that perspective - making the language more difficult to work with (for non-technical people).

This is exactly why Python should be further simplified, and not made more complex - given the population which uses it most.

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

#417

Post by commonlisp94 »

csmpltn wrote: post #410
usrbinbash wrote: post #367

Earlier quoted context omitted.

> The fact of the matter is that Python (already today) allows you to achieve parallelism across both IO-bound and CPU-bound workloads. I also don't need to use goroutines. I could simply spin up my golang application as a couple of processes, and use pipes and other IPC to coordinate them. "There is another way to do X" doesn't imply that other way is better.

> "doesn't imply that other way is better" I never said that multiprocessing is "better" than multithreading. Both are mechanisms to achieve parallelism with different pros/cons, and there are legit cases where threads are a necessity that can't be satisfied with processes (ref my previous comment with examples). This conversation would've been much easier to have given specific constraints and examples (which nobody…

I completely agree with this position. If you need an optimized paralyzed code to chew through a tough workload, write that part in C, and spawn it from python. Python is a coordinating scripting language.

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

#418

Post by commonlisp94 »

usrbinbash wrote: post #364
miraculixx wrote: post #327

Earlier quoted context omitted.

Progress in the name if progress is rarely a good choice. The key question that remains unanswered is Why should Python even need a free threading model? There are no good answers afaik.

> There are no good answers afaik. I shall be more than happy to provide them: Supporting thread based parallelism is the norm among all mainstream PLs with the one inglorious exception of JS, which doesn't because it simply can't. And Python already does support it, it simply is limited by a legacy design decision. That was okay in a bygone age when fast single core machines were still the norm, Python was primarily…

> because it simply can't.

It can't for the same reason python can't - every part was designed without it in mind.

> Python already does support it

The language runtime might have it in a branch, but the vast majority of C code it is based on, and the scripts themselves assume otherwise.

> fast single core machines

Once again, if you are using python as a scripting language, with C libraries, and spawning processes, you are already utilizing multiple cores without any adjustment on your part.

> CPU bound workloads become ever more important.

If that's true, then you shouldn't use python. It's about 100x slower than C. How much performance can you squeeze out of dividing work into cooperating threads, that can't be easily achieved by having multiple processes.

In the "web application" example you are using, the norm is already to have many processes to handle incoming connections.

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

#419

Post by soulbadguy »

csmpltn wrote: post #410
usrbinbash wrote: post #367

Earlier quoted context omitted.

> The fact of the matter is that Python (already today) allows you to achieve parallelism across both IO-bound and CPU-bound workloads. I also don't need to use goroutines. I could simply spin up my golang application as a couple of processes, and use pipes and other IPC to coordinate them. "There is another way to do X" doesn't imply that other way is better.

> "doesn't imply that other way is better" I never said that multiprocessing is "better" than multithreading. Both are mechanisms to achieve parallelism with different pros/cons, and there are legit cases where threads are a necessity that can't be satisfied with processes (ref my previous comment with examples). This conversation would've been much easier to have given specific constraints and examples (which nobody…

> I never said that multiprocessing is "better" than multithreading.

Maybe not, but you seem to be implying that multiprocessing is a sufficient for the most case (or the average case ?) however ill define that average case is.

> This conversation would've been much easier to have given specific constraints and examples (which nobody seems to give).

Not quite, there is no need grand example here, processes vs threads is just a function of how chatty the interaction between the independent agent are. We should have both mechanism available and let the user choose.

> My main argument, if you distill it down to the abstract, is "use the right tool for the job" - and stop pretending that a hammer and a knife are the same thing, when they're not.

You don't get to decide in the abstract what the right tool is for other people and context we don't know anything about. The people pushing for proper threading are telling you that for them python + better threading is the right tool.

> If you need hardcore, ultra efficient and parallelized workflows - Python is just the wrong tool for the job period. This isn't up for debate - it's a given fact.

Maybe; But that's not the point here. Proper threading in python doesn't make python more efficient, but it makes the * scaling * of python performance more efficient. Those are two differents things.

> Python fills a niche of its own incredibly well, something which others tools suck at, and Python is loved by millions for it.

> This whole discussion now (GIL vs. no GIL) is about bending and twisting Python to fit the use cases of few companies like DeepMind or Facebook

> who I'm certain represent a miniscule usage compared to the millions of students, schools and universities, research institutes, web shops, hobbyists, tinkerers, etc. Those people want to get shit done quickly - and mutexes, sempahores, events, threads, synchronization primitives, atomics, etc - will do nothing but make their lives a misery, and drive them away.

This seems to me like the core of the problem, somehow you say that there is no valid need for threading, but at the same time the people needing threading are not important enough for python to care about... You have the magical ability to be plug into the python hivemind and decide which use case are valid, what are the true value of the python community and what python should and should not consider important... And after all that mental gymnastic you expect us to jump through hoops to convince you otherwise...

That's a lot of non technical assumption for a technical problem.

> Those people want to get shit done quickly - and mutexes, sempahores, events, threads, synchronization primitives, atomics, etc - will do nothing but make their lives a misery, and drive them away.

Not really. If anything, they will benefits from better libraries and more efficient C-extensions.

> absolutely needs multithreading

Nothing is absolutely needed. Even something are core as a type system is not absolutely needed. The fact that you ask for this level of qualification for a feature that pretty much every other language has is the problem.

The problem is not that deep, implementing multi-threading is not that complicated. I do agree that we need to be careful to provide a better API than raw-thread to end users (which no-gil is COMPLETLY agnostic about).

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

#420

Post by soulbadguy »

commonlisp94 wrote: post #53
jmount wrote: post #46

Why would you even want a no-GIL Python? Java and C showed how much more effort it takes to maintain slower thread safe code for no real benefit. Parallelize at the fork level or at the isolated numeric library level.

Exactly. I think a lot of the negativity about GIL comes from a misunderstanding about forking processes. If python is being used as a scripting language, and spawning other tools, you're already getting free multi-core. A similar misunderstanding exists about SQLite and concurrency.. but that's a topic for another time.

> If python is being used as a scripting language

And when it's not ?

Post reply on HN