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

381–390 of 513 posts

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

#381

Post by Arch-TK »

pseudocomposer wrote: post #191
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.

I agree that Rust handles concurrency about as well as Java (in addition to its memory safety). But could you provide docs on Erlang or Haskell concurrent data structures that were better than Java’s, say, 10-20 years ago? Java’s support for concurrent data structures was pretty unprecedented in its heyday.

Erlang processes are a first class object. Data is immutable. There's a special syntax for sending and receiving messages between processes.

I would say that in some ways this is simply incomparable to java but I think this concurrency model is probably the easiest and simplest to work with of any concurrency model.

There are obviously drawbacks like with anything but for a lot of situations it's an excellent choice.

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

#382

Post by gjulianm »

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…

> is there any use case of No-GIL which is not solved by multiprocessing ?

Tons:

- A web server that responds using shared state to multiple clients at the same time.

- multiprocessing uses pickle to send and receive data, which is a massive overhead in terms of performance. Let’s say you want to do some parallel computations on a data structure, and said structure is 1GB in memory. Multiprocessing won’t be able to deal with it with good performance.

- Another consequence of using pickle is that you can’t share all types of objects. To make matters worse, errors due to unpickable objects are really hard to debug in any non-trivial data structure. This means that sharing certain objects (specially those created by native libraries) can be impossible.

- Any processing where state needs to be shared during process execution is really hard to do with the multiprocessing module. For example, the Prometheus exporter for Flask, which only outputs some basic stats for response times/paths/etc, needs a weird hack with a temporary directory if you want to collect stats for all processes.

I could go on, honestly. But the GIL is a massive problem when trying to do parallelism in Python.

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

#383

Post by usrbinbash »

n2d4 wrote: post #356
usrbinbash wrote: post #294

Earlier quoted context omitted.

> asyncio ...is useless for CPU bound tasks. The event loop uses only one core. > multiprocessing ...relies on IPC and running actual system processes, both of which have alot more overhead than switching thread context and using shared memory. > For any use case where the last few percent matter, consider not using Python (which will be much much more significant). Here is an interesting question: If asyncio and mul…

If you're interested, I wrote a more elaborate comment on asyncio vs. multiprocessing vs. multithreading here: https://news.ycombinator.com/item?id=36915581 (fyi, Python's multiprocessing has support for interprocess shared memory, with overhead) Those languages you mentioned are not only recommended to escape parallelism problems in Python. They are recommended because they are much, much faster, period. Four of tho…

> (fyi, Python's multiprocessing has support for interprocess shared memory, with overhead)

I know. I have a werkzeug/gunicorn application that currently runs 60 worker processes on a 64 core server.

And I would love nothing better than to rip out every. single. last. one. of the IPC facilities, and replace them with the same easy and convenient mutex and CSP systems, that I can use in my Golang applications.

> They are recommended because they are much, much faster, period.

I know, but "rewrite it in Rust/Go/C++" isn't always an option, be it because of legacy status, constraints in available dev-hours, compatibility problems, library support or simply ease of use.

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

#384

Post by samus »

lanstin wrote: post #110
winter_blue wrote: post #102

Earlier quoted context omitted.

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…

Because with the GIL it was dead simple to glue a C library into Python, and also was the canonical way to address hot inner loops in Python: rewrite into C. Nothing fancy but a little trial and error with module loading and you get 30% speed ups without being a great C programmer. I don’t think it’s false to say that the ease of moving hot spots into C is part of the reason Python has been so successful for thirty y…

C extensions are a different use case than accessing a C library using `ctypes`. The former allows intimate interactions with Python objects and therefore requires the GIL. The latter should only cause trouble if the C library executes callbacks on another thread. In that case, a Python thread is created for every invocation, which could cause race conditions with Python code. However, this problem also exists in GIL mode. In most cases, foreign libraries usually have Pythonic wrappers that should prevent some of these issues.

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

#385

Post by eesmith »

otabdeveloper4 wrote: post #267
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…

> originally was an embeddable extension language Python was originally a teaching language, to replace BASIC and Pascal for kids and beginners. (Yes, there once was a time when people took teaching programming seriously.)

Python was not originally a teaching language.

Yes, van Rossum was an implementer of ABC, which was a teaching language. Python drew on that experience, but also from Modula-2 and Modula-3, and the needs for writing an extension language for the Amoeba operating system.

From the initial release notes at https://www.tuhs.org/Usenet/alt.sources/1991-February/001749... :

  [Python is] an extensible interpreted programming language that
  combines remarkable power with very clear syntax.
  
  This is version 0.9 (the first beta release), patchlevel 1.
  
  Python can be used instead of shell, Awk or Perl scripts, to write
  prototypes of real applications, or as an extension language of large
  systems, you name it.
No mention of it being a teaching language.

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

#386

Post by samus »

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…

PEP-703 contains a whore Motivation section. Long enough to require a summary:

> Python’s global interpreter lock makes it difficult to use modern multi-core CPUs efficiently for many scientific and numeric computing applications. Heinrich Kuttler, Manuel Kroiss, and Paweł Jurgielewicz found that multi-threaded implementations in Python did not scale well for their tasks and that using multiple processes was not a suitable alternative.

> The scaling bottlenecks are not solely in core numeric tasks. Both Zachary DeVito and Paweł Jurgielewicz described challenges with coordination and communication in Python.

> Olivier Grisel, Ralf Gommers, and Zachary DeVito described how current workarounds for the GIL are “complex to maintain” and cause “lower developer productivity.” The GIL makes it more difficult to develop and maintain scientific and numeric computing libraries as well leading to library designs that are more difficult to use.

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

#387

Post by xmcqdpt2 »

JonChesterfield wrote: post #249

Exciting. Python is mostly written as C shared libraries that knew they had a global lock to rely on. Some of those do sufficiently simple things that they can run without any locking and all will be fine. Others will still need locking, but are now under pressure to run without the gil. Some of those are going to do DIY locking within their own bounds. Maybe what python has really been missing all these years is loa…

Most C libraries that are often called from python also have bindings for other languages and so at this point should be threadsafe, right? Also even GIL python supports threads so all these libraries will at least be reentrant safe already.

For libraries that are reentrant but not thread safe, it should be sufficient to just add a global lock wrapping every call, which is pretty close to what the GIL was doing anyway.

It seems to me that in many (most?) cases it should be relatively straightforward to make existing libraries work without the GIL (at the cost of parallelism). I guess the main issue will be for libraries that call back into the python runtime from the C side.

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

#388

Post by tgv »

fred123 wrote: post #233
slt2021 wrote: post #78

Earlier quoted context omitted.

even if they get "free multithreading" with no-GIL, their system eventually will overgrow one beefy machine and will need to be deployed across a fleet of 10/100/1000 machines. at which point you lose benefit of no-GIL, because you now have to introduce redis and kafka into the system

Why? On AWS you can rent a 24 TB, 500 core machine. Almost all problems are smaller than that so don’t need to scale to more than one machine. Building applications that run on multiple machines is at least one order of magnitude more complex and thus slower (in development velocity), so needlessly building an application to work distributedly is just bad engineering.

Dear Lord, is that real? It surely would not be appropriate to compensate for bad performance in a Python app.

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

#389

Post by samus »

viraptor wrote: post #160
raminf wrote: post #152

Remember the transition of text to Unicode? 32 to 64-bit? Intel to ARM? Y2K? No-GIL is a much smaller shift. It can follow the same transition path without radically breaking things. And if some things do break, there would be a well-defined way to handle those cases. We all somehow survived those. Glad to see forward motion on this. It will open up a lot more terrain that has been marked off as untenable. One of the…

I think that's a bit different. 32 to 64 - you could test whether it works. Same for arm. Same for y2k. Sure, maybe the testing wouldn't cover the failing case, but the testing you did would be deterministic. But here? Test all you want and the answer is: it's either correct or you haven't triggered the right race yet.

Yes, it is different because nobody would be forced to run the interpreter without the GIL. Applications where race conditions are unacceptable can keep using the GIL build. Even the `--disable-gil` build can be forced to keep using the GIL.

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

#390

Post by tgv »

r0l1 wrote: post #325
csmpltn wrote: post #245

Earlier quoted context omitted.

> "Python is just a pain in terms of using all system resources" Whatever this comment means (I honestly can't properly tell) - removing the GIL will have absolutely no impact on Python's resource utilization.

https://peps.python.org/pep-0703/ Quote: "In PyTorch, Python is commonly used to orchestrate ~8 GPUs and ~64 CPU threads, growing to 4k GPUs and 32k CPU threads for big models. While the heavy lifting is done outside of Python, the speed of GPUs makes even just the orchestration in Python not scalable. We often end up with 72 processes in place of one because of the GIL. Logging, debugging, and performance tuning are…

And they couldn't switch to another language? It sounds really odd to me, too odd to be a justification for this change.
Post reply on HN