4 ms·

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

by 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.
- gaius 9y ago
  Right, hence me making that caveat. multiple up-and-coming or even moderately-popular languages now which have as a design feature the inability to do such a thing STM in Haskell seems quite promising, but the approach of just outsourcing that problem to Redis gets you pretty far.

by gaius 9y ago

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.

gaius 9y ago
Right, hence me making that caveat. multiple up-and-coming or even moderately-popular languages now which have as a design feature the inability to do such a thing STM in Haskell seems quite promising, but the approach of just outsourcing that problem to Redis gets you pretty far.