Hacker News Reader

Comment by qwerty456127 | Hacker News Reader

> The GIL also means that whilst CPython can be multi-threaded, only 1 thread can be executing at any given time.

How does this make sense? What's the point of having multiple threads then?

It could be better phrased: "whilst CPython can be multi-threaded, only 1 thread can be executing Python code at any given time." Other threads can be doing other things at the same time -- just not actively interpreting Python bytecode.

It is because only one thread at a time holds the lock in order to avoid race conditions. The keynote[1] by Raymond Hettinger from PyBay '17 will be a great place to start if you are new to this.

[1] https://youtu.be/9zinZmE3Ogk

Not all operations are CPU bound. For anything that is IO bound, such as reading a file, db access, network calls, etc, CPython threads work just fine.

And even for CPU bound programs, if your CPU is running non-Python code (e.g. numpy functions that call to FORTRAN/C) then CPython threads still work.

Until someone adds a callback from C back into Python and the unexpected GIL contention makes performance dramatically worse even as compared to the single-threaded version.

some C libraries release the GIL before running CPU intensive computations. Examples include numpy and hashlib.

Parallelism allows multiple threads interleave with each other. It does not guarantee parallelism (two or more threads executing at the same time). It's similar to multiple threads operating on a uniprocessor system, with the difference that I/O can happen in parallel.

I believe this is still beneficial in I/O bound processes.

The usual answer is: in the case of blocking I/O, the thread running send/recv can block while other python code runs.

In practice, this doesn’t work particularly well, as you rarely have massively I/O bound things in Python.

Not sure what kind of applications you work on, but most web apps are IO bound (waiting on network calls).

I'm not the person you were originally responding to, but I know Python is popular in data science and such where there would be a lot more tied up in pure computation/number crunching.

I know that you already got an answer to this effect, but to provide some more information, most data science workflows in Python rely heavily on calls into numerical libraries (numpy, scipy, pandas, tensorflow, pytorch, matplotlib) that are Python wrappers over compiled binaries (mostly C and Fortran, a not-inconsiderable amount of handwritten Assembly), that have been constructed so that the wrapper safely yields the GIL before invoking the underlying binary. This is all the more important when considering libraries like tensorflow or pytorch that may involve complex long-running interaction with training resources across a network. Control is yielded to allow the interpreter to continue carrying out tasks like displaying the ongoing training progress, or loading training data.

To that point, most third-party libraries used also delegate the number crunching to C/C++ code, so most time is still spent outside the GIL.

I should have clarified: when I meant "doesn't work particularly well", I meant that its incredibly difficult to saturate say a 100 thread box. (Which with Rome isn't crazy!)

Only being able to run a single thread of "logic" basically makes that impossible, as you need to usually do some computation to figure out what bytes to send/receive, do something with the results, and so on.

The program doesn't have to be massively I/O bound for threads to be useful. Even with only a UI thread and a single background thread they're useful for animating a progress indicator in the UI thread while waiting for a slow network request to finish in the background thread, which works just fine in Python.

> you rarely have massively I/O bound things in Python.

Citation needed.

Reply on news.ycombinator.com