5 ms·

It's funny, I've written a lot of python in quite a few domains and haven't really struggled directly because of the GIL before. Is this more of a 'data scienti

It's funny, I've written a lot of python in quite a few domains and haven't really struggled directly because of the GIL before. Is this more of a 'data scientist' problem? I feel like if I had a huge pile of data to crunch, python wouldn't be my first choice really.

askvictor 9y ago
Strangely, python is the choice for heaps of (data and other) scientists, mainly as it's so easy to pick up and tooling (jupyter) - remember that these people aren't native coders. And even then parallelism is handled behind the scenes with libraries such as scipy and numpy. I think the problems come up when you have a high performance application that doesn't play nice with numpy or scipy
prewett 9y ago
Servers are where the problem is. The GIL makes python functionally single-threaded, which is a bummer for your server at any kind of scale. So you end up having to have n cores' worth of server processes behind a load balancer, even if you only need one server machine, which is a bummer if a you have a stateful server (such as a game server), as you now have to manage communicating state between processes by storing it in another process (frequently Redis). But python is easy and fun to write code in, and "developer time is expensive, servers are cheap," so there are a lot of python servers which could benefit from a lack of GIL. Never mind that it's fast to write, but difficult to maintain since it is a dynamically typed language and one typo creates runtime errors that any statically typed language will catch at compile time. Or that it is slow. Or that a python process never really releases memory back to the system, just within itself, so the process slowly grows over the course of a few weeks. Or that the Twisted framework you're using for cooperative multitasking because of the GIL is really easy to block on a database query by accident, leading to uncooperative multitasking (= large lags), resulting to forced server restarts, and loss of players (= loss of revenue). So yeah, "developer time is cheap" but it's sort of an expensive cheap. I came to the conclusion that python is unsuitable for servers, but until Go came out, there wasn't a realistic alternative, since C++ and Java are too heavyweight, and Ruby suffers from similar problems (don't know about a GIL).
- thomaslee 9y ago
  > Servers are where the problem is. The GIL makes python functionally single-threaded, which is a bummer for your server at any kind of scale. Right, agreed. I can imagine some of the frustration you might experience using CPython for high throughput systems: kind of like NodeJS without the benefits of a standard library written with async/non-blocking I/O in mind. A bit curious about a few things you mention here, though: > Or that a python process never really releases memory back to the system, just within itself, so the process slowly grows over the course of a few weeks. I'm not sure this is true in general, is it? Can you elaborate? It's been a while since I've dug around in Python innards, but if Py_DECREF(x) leads to a refcount of zero IIRC free(x) is ultimately called -- albeit in an indirect manner via a layer or six of tp_dealloc calls and tp_free. :) I suppose calling free(x) may only return the memory associated with x to (g)libc's free list and not necessarily back to the OS [0]. No different to C/C++ in that regard, I guess. > I came to the conclusion that python is unsuitable for servers, but until Go came out, there wasn't a realistic alternative, since C++ and Java are too heavyweight, and Ruby suffers from similar problems (don't know about a GIL). "Too heavyweight" in that they're relatively difficult to write in comparison? Maybe true of Java-the-language, but the JVM itself is an absolute workhorse when it comes to high performance. Plenty of languages to choose from there, typically without a GIL. Jython, for example, has no GIL [1]. And yep, Ruby/MRI has a GIL (but JRuby does not). [0] https://www.gnu.org/software/libc/manual/html_node/Freeing-after-Malloc.html https://www.gnu.org/software/libc/manual/html_node/Freeing-a... [1] https://stackoverflow.com/questions/1120354/does-jython-have-the-gil/1147548#1147548 https://stackoverflow.com/questions/1120354/does-jython-have...
  - fiddlerwoaroof 9y ago
    Common Lisp implementations generally do multithread really well and give you lovely syntactic abstraction capabilities while also running significantly faster than comparably high-level languages.
- jabl 9y ago
  > I came to the conclusion that python is unsuitable for servers, but until Go came out, there wasn't a realistic alternative, since C++ and Java are too heavyweight, and Ruby suffers from similar problems (don't know about a GIL). If you're willing to go slightly outside the mainstream, there's stuff like erlang and haskell with kickass runtimes. And haskell, at least, is pretty strongly typed.
chrisseaton 9y ago
> if I had a huge pile of data to crunch, python wouldn't be my first choice really. Right - and one reason that it wouldn't be your first choice would be the GIL, so let's remove the GIL, and then the other barriers.
- gaius 9y ago
  one reason that it wouldn't be your first choice would be the GIL I don't think this is true. GIL means Global Interpreter Lock - it isn't held when you are in native code, which is how NumPy et al actually work - Python to marshal the data, then do the heavy lifting under the hood in C, FORTRAN and ASM, that the end user never needs to see. So this is a non-problem. As the above comment says, the problem is if you want to write a server that handles a lot of concurrency and shared state.
  - chrisseaton 9y ago
    I think there's a bit of Amdahl's law to this. You could have most of your application in NumPy, running beautifully in parallel on your 64-core machine, but then you just need to drop back into Python to do a tiny bit of transformation or logging or something before you go back into NumPy, it's really quick, but because all 64 cores contend you do that work inside the GIL you then have yourself a sequential bottleneck. Even if it's small, it starts to dominate.
    - gaius 9y ago
      Sure but that would be the case if you were marshalling data to/from a GPU too.
  - ubernostrum 9y ago
    As the above comment says, the problem is if you want to write a server that handles a lot of concurrency and shared state. If you write a server and it uses threading as the concurrency model and its workload is primarily CPU-bound, the GIL will be a problem for you. Take away either of those conditions -- use a model other than threading, or have an I/O-bound workload -- then the normal background overhead of the GIL is not something you'll notice. People who deploy Python applications as network daemons tend to use pools of worker processes (not threads) and have I/O-bound workloads, which is why the assertion that Python is somehow "bad for servers" is not one you'll typically hear from people who actually deploy Python on servers. Much like the comment you're referring to, which is from someone who seems to primarily have type-system complaints about Python (i.e., they wouldn't touch a dynamically-typed language to begin with) and is throwing in "oh and the GIL probably makes it unsuitable for a server" as an additional (but factually incorrect) reason not to use Python. Meanwhile, if you are writing a server which uses threading and lots of shared state which will be modified concurrently, you're in for a world of pain no matter what language you choose. There's a reason why there are multiple up-and-coming or even moderately-popular languages now which have as a design feature the inability to do such a thing.
bayesian_horse 9y ago
Actually, the data science stack is pretty much unconstrained by the GIL right now. Most of the libraries do their work in C/Fortran, and release the GIL in-between. For that matter you should look into Theano, Tensorflow and Numba to bring Python code to the GPU (no GIL there). Or use Dask to scale to multiple cores or nodes.
jackmott 9y ago
some things need performance some don't. that simple.
a3n 9y ago
If we didn't have GIL issues, then you may have written python in additional domains that the GIL makes impractical or weakly advised. And then, thought experiment, if the GIL were suddenly introduced, we'd be pissed.

askvictor 9y ago

Strangely, python is the choice for heaps of (data and other) scientists, mainly as it's so easy to pick up and tooling (jupyter) - remember that these people aren't native coders. And even then parallelism is handled behind the scenes with libraries such as scipy and numpy. I think the problems come up when you have a high performance application that doesn't play nice with numpy or scipy

prewett 9y ago

Servers are where the problem is. The GIL makes python functionally single-threaded, which is a bummer for your server at any kind of scale. So you end up having to have n cores' worth of server processes behind a load balancer, even if you only need one server machine, which is a bummer if a you have a stateful server (such as a game server), as you now have to manage communicating state between processes by storing it in another process (frequently Redis). But python is easy and fun to write code in, and "developer time is expensive, servers are cheap," so there are a lot of python servers which could benefit from a lack of GIL. Never mind that it's fast to write, but difficult to maintain since it is a dynamically typed language and one typo creates runtime errors that any statically typed language will catch at compile time. Or that it is slow. Or that a python process never really releases memory back to the system, just within itself, so the process slowly grows over the course of a few weeks. Or that the Twisted framework you're using for cooperative multitasking because of the GIL is really easy to block on a database query by accident, leading to uncooperative multitasking (= large lags), resulting to forced server restarts, and loss of players (= loss of revenue). So yeah, "developer time is cheap" but it's sort of an expensive cheap. I came to the conclusion that python is unsuitable for servers, but until Go came out, there wasn't a realistic alternative, since C++ and Java are too heavyweight, and Ruby suffers from similar problems (don't know about a GIL).

thomaslee 9y ago
> Servers are where the problem is. The GIL makes python functionally single-threaded, which is a bummer for your server at any kind of scale. Right, agreed. I can imagine some of the frustration you might experience using CPython for high throughput systems: kind of like NodeJS without the benefits of a standard library written with async/non-blocking I/O in mind. A bit curious about a few things you mention here, though: > Or that a python process never really releases memory back to the system, just within itself, so the process slowly grows over the course of a few weeks. I'm not sure this is true in general, is it? Can you elaborate? It's been a while since I've dug around in Python innards, but if Py_DECREF(x) leads to a refcount of zero IIRC free(x) is ultimately called -- albeit in an indirect manner via a layer or six of tp_dealloc calls and tp_free. :) I suppose calling free(x) may only return the memory associated with x to (g)libc's free list and not necessarily back to the OS [0]. No different to C/C++ in that regard, I guess. > I came to the conclusion that python is unsuitable for servers, but until Go came out, there wasn't a realistic alternative, since C++ and Java are too heavyweight, and Ruby suffers from similar problems (don't know about a GIL). "Too heavyweight" in that they're relatively difficult to write in comparison? Maybe true of Java-the-language, but the JVM itself is an absolute workhorse when it comes to high performance. Plenty of languages to choose from there, typically without a GIL. Jython, for example, has no GIL [1]. And yep, Ruby/MRI has a GIL (but JRuby does not). [0] https://www.gnu.org/software/libc/manual/html_node/Freeing-after-Malloc.html https://www.gnu.org/software/libc/manual/html_node/Freeing-a... [1] https://stackoverflow.com/questions/1120354/does-jython-have-the-gil/1147548#1147548 https://stackoverflow.com/questions/1120354/does-jython-have...
- fiddlerwoaroof 9y ago
  Common Lisp implementations generally do multithread really well and give you lovely syntactic abstraction capabilities while also running significantly faster than comparably high-level languages.
jabl 9y ago
> I came to the conclusion that python is unsuitable for servers, but until Go came out, there wasn't a realistic alternative, since C++ and Java are too heavyweight, and Ruby suffers from similar problems (don't know about a GIL). If you're willing to go slightly outside the mainstream, there's stuff like erlang and haskell with kickass runtimes. And haskell, at least, is pretty strongly typed.

chrisseaton 9y ago

> if I had a huge pile of data to crunch, python wouldn't be my first choice really. Right - and one reason that it wouldn't be your first choice would be the GIL, so let's remove the GIL, and then the other barriers.

gaius 9y ago
one reason that it wouldn't be your first choice would be the GIL I don't think this is true. GIL means Global Interpreter Lock - it isn't held when you are in native code, which is how NumPy et al actually work - Python to marshal the data, then do the heavy lifting under the hood in C, FORTRAN and ASM, that the end user never needs to see. So this is a non-problem. As the above comment says, the problem is if you want to write a server that handles a lot of concurrency and shared state.
- chrisseaton 9y ago
  I think there's a bit of Amdahl's law to this. You could have most of your application in NumPy, running beautifully in parallel on your 64-core machine, but then you just need to drop back into Python to do a tiny bit of transformation or logging or something before you go back into NumPy, it's really quick, but because all 64 cores contend you do that work inside the GIL you then have yourself a sequential bottleneck. Even if it's small, it starts to dominate.
  - gaius 9y ago
    Sure but that would be the case if you were marshalling data to/from a GPU too.
- ubernostrum 9y ago
  As the above comment says, the problem is if you want to write a server that handles a lot of concurrency and shared state. If you write a server and it uses threading as the concurrency model and its workload is primarily CPU-bound, the GIL will be a problem for you. Take away either of those conditions -- use a model other than threading, or have an I/O-bound workload -- then the normal background overhead of the GIL is not something you'll notice. People who deploy Python applications as network daemons tend to use pools of worker processes (not threads) and have I/O-bound workloads, which is why the assertion that Python is somehow "bad for servers" is not one you'll typically hear from people who actually deploy Python on servers. Much like the comment you're referring to, which is from someone who seems to primarily have type-system complaints about Python (i.e., they wouldn't touch a dynamically-typed language to begin with) and is throwing in "oh and the GIL probably makes it unsuitable for a server" as an additional (but factually incorrect) reason not to use Python. Meanwhile, if you are writing a server which uses threading and lots of shared state which will be modified concurrently, you're in for a world of pain no matter what language you choose. There's a reason why there are multiple up-and-coming or even moderately-popular languages now which have as a design feature the inability to do such a thing.

bayesian_horse 9y ago

Actually, the data science stack is pretty much unconstrained by the GIL right now. Most of the libraries do their work in C/Fortran, and release the GIL in-between. For that matter you should look into Theano, Tensorflow and Numba to bring Python code to the GPU (no GIL there). Or use Dask to scale to multiple cores or nodes.

jackmott 9y ago

some things need performance some don't. that simple.

a3n 9y ago

If we didn't have GIL issues, then you may have written python in additional domains that the GIL makes impractical or weakly advised. And then, thought experiment, if the GIL were suddenly introduced, we'd be pissed.