4 ms·

GIL is one of the things that make Python an annoyance to work with. In saner languages, you could handle multiple requests at the same time, or easily spin som

GIL is one of the things that make Python an annoyance to work with. In saner languages, you could handle multiple requests at the same time, or easily spin something off in a thread to work in the background. In Python you can't do this. You need to duplicate your process, then pay the price of memory usage and other things multiple processes hinder (like communication between threads or pre-computed values now aren't shared so you need something external again). To deploy your app, you end up with 10 different deploys because each of them have to have a different entry point and separate task to fulfill.

stinos 3y ago
GIL is one of the things that make Python an annoyance to work with For your particular usecase, yes. Personally I've been using Python for like 20 years for various tasks and so far never got really bothered by the presence of it once. Worst case was having to wait somewhat longer for things to complete. For my case: still worth it compared to making things multithreaded. And async fixed the rest. And the things which I actually need to be fast aren't usually in Python anyway. I'm not saying the GIL should stay, it's just that it doesn't seem as much of a problem in the general land of Python. Or in other words: how many Python users out there even know what GIL means and does?
- stult 3y ago
  > For your particular usecase, yes. The use case they are describing is a standard web server or web application. That's a pretty important and widely applicable use case to dismiss out of hand as "your particular usecase".
  - nomel 3y ago
    > The use case they are describing is a standard web server or web application. I believe this is what they were referring to when they said “async fixed the rest”.
  - nunuvit 3y ago
    The dismissiveness really goes the other way. Pythons like IronPython and Jython don't have a GIL. CPython does because it's primarily a glue language for extensions that might not be thread-safe. Web apps were given huge accommodation with async, so you can't say their needs are being dismissed. Why must we break the C in CPython for a use-case that could use one of the GIL-free Pythons?
  - semiquaver 3y ago
    The GIL is not held during IO, which is what most web applications and web servers should be spending the vast majority of their time doing. https://docs.python.org/3/library/threading.html https://docs.python.org/3/library/threading.html If that’s too limiting, preforking and other forms of process-based parallelism are a tried and true approach that has been used for years to run python, ruby, PHP, and once upon a time Perl web applications at enormous scale. The difference between threads and processes on Linux is relatively minor. Saying that python doesn’t work for web application use cases because of the GIL is frankly sort of bizarre given the large number of python web applications in the wild chugging along delivering value.
    - jrochkind1 3y ago
      > The GIL is not held during IO, which is what most web applications and web servers should be spending the vast majority of their time doing. While this has been oft-repeated for years, more or less language-independently, I have become convinced it no longer accurately describes ruby on rails apps. People still say it about ruby/rails too though. But my rails web apps are spending 50-80% of their wall time in cpu, rather than blocking on IO. Depending on app and action. And whenever I ask around for people who have actual numbers, they are similar -- as long as they are projects with enough developer experience to avoid things like n+1 ORM problems. I don't have experience with python, so I can't speak to python. but python and ruby are actually pretty similar languages, including with performance characteristics, and the GIL. Python projects tend to use more stuff that's in C, which would make more efficient use of CPU, so that could be a difference. (Also not unrelated to what we're talking about!) But I have become very cautious of accepting "most web applications are spending the vast majority of their time on io blocking rather than CPU" as conventional wisdom without actually having any kind of numbers. vast majority? I would doubt it, but we need empirical numbers.
      - zarzavat 3y ago
        But are they CPU limited? There’s a difference between spending most of your time in CPU, and being CPU limited. If I’m serving 10 requests/second then even if I’m 90% CPU and 10% IO, it doesn’t matter because I’m 99% idle. My mental model for a very high-interpreter overhead language like Ruby or Python for webdev, is that it is appropriate for sites that don’t see that much absolute interactive traffic. e.g. it’s good for a blog where you can put a cache in front of it, or an intranet service where you control the number of users. I would never use Python for a fully interactive high traffic service sitting on the open internet. There are languages that are much better at that.
  - stinos 3y ago
    That's somewhat out of context. With the bit you quoted I meant "sure working around the GIL by implemening a web server in that particular way is annoying". I'm not saying that "web server" as a whole is not important or not widely applicable, merely that amongst all other usecases and applications of Python out there, web servers are just one of many. And the particular implementation stated like "10 different deploys" is even a subset of that 'one' and as explained by fellow comments, probably not the most appropriate one.
- Fiahil 3y ago
  I think Data Scientists would like a word with you. They have plenty of time since their parallel pipeline was OOMKilled.
paulddraper 3y ago
Other languages do that: JavaScript, PHP, Erlang. Python multiprocessing is pretty usable. I like multithreading, but also...it has more footguns then the rest of programming combined. [1] I'm not convinced Python's approach is that bad in practice. [1] https://news.ycombinator.com/item?id=22165193 https://news.ycombinator.com/item?id=22165193
- deleted 3y ago
  [deleted]
- mohaine 3y ago
  It is, until the GIL bites you in the ass. As it is you get different behavior if your call is calling out to external code vs being pure python. Note that you really don't know if a random function call is python or wrapping external class so you really get random behavior. The time it got me was a thread just to timeout another process. Tests worked great but the timeout didn't work in production because the call it was wrapping was calling out to C code so nothing would run until the call returned. We even still got the timeout error in the logs and it looked like it was working (it even tossed the now waited for valid results), but not at the time of the timeout but after the call finally returned a few hours later.
  - paulddraper 3y ago
    So.... It would have been better if GIL were even more aggressive?
ActorNightly 3y ago
The other languages are not saner. You are basically saying "Python GIL is annoying because I can't write parallel processing performant code in Python". Python has never been and is not a performant language. Its designed for rapid and easy development. The multiprocessing+asyncio in Python fulfills the aspect of utilizing all the resources, albeit at a higher memory cost, but memory is dirt cheap these days. You have a master process and then worker threads. For all things that you would write in Python, where in >90% cases you are network latency limited, the paradigm of a master process and worker processes with IPC on unix sockets works extremely well. Set up a web app with fast api/gunicorn master/uvicorn workers, and it will be plenty fast enough for anything you do.
oconnor663 3y ago
> you could handle multiple requests at the same time To be fair to Python and the GIL, it's totally capable of parallelizing requests when most of the work is network-bound, which is probably the common case. And when the work is CPU-bound, but the CPU-intensive part is written in C, it's also possible for C to release the GIL. So it's really only "heavy computational work directly in Python" programs that are affected by this. (On the other hand, Python applications do naturally expand to look like this over time...)
slt2021 3y ago
No it is not. If you want to reach peak performance single-threaded app with no locks is the way to go, and work being sharded (not shared) among multiple single-threaded apps. Multi-threaded apps with shared state introduce more complexity, than the performance when compared to multiple single-threaded apps running asyncio event loop. For example LMAX Disruptor
gnulinux 3y ago
This is your opinion, but many disagree. I personally find processes infinitely easier to deal with than thread, it's not even a discussion in my mind. For me, threads are banned from usage, until it's absolutely necessary to do so. When I write code in C++ there are cases where a problem cannot be solved unless threads are used. It's fine to use threads there. For everything else I appeal to either multiprocessing or `async` concurrency.
hgs3 3y ago
> You need to duplicate your process, then pay the price of memory usage ... I believe the implementation of the Python multiprocessing package uses fork() on *nix systems which means memory should be copy-on-write. Processes do have the advantage of being self-contained meaning if one crashes, then it will not take down the entire system. Also, the message passing model can theoretically scale to processes running on separate hardware. Thread's cannot do that.

stinos 3y ago

GIL is one of the things that make Python an annoyance to work with For your particular usecase, yes. Personally I've been using Python for like 20 years for various tasks and so far never got really bothered by the presence of it once. Worst case was having to wait somewhat longer for things to complete. For my case: still worth it compared to making things multithreaded. And async fixed the rest. And the things which I actually need to be fast aren't usually in Python anyway. I'm not saying the GIL should stay, it's just that it doesn't seem as much of a problem in the general land of Python. Or in other words: how many Python users out there even know what GIL means and does?

stult 3y ago
> For your particular usecase, yes. The use case they are describing is a standard web server or web application. That's a pretty important and widely applicable use case to dismiss out of hand as "your particular usecase".
- nomel 3y ago
  > The use case they are describing is a standard web server or web application. I believe this is what they were referring to when they said “async fixed the rest”.
- nunuvit 3y ago
  The dismissiveness really goes the other way. Pythons like IronPython and Jython don't have a GIL. CPython does because it's primarily a glue language for extensions that might not be thread-safe. Web apps were given huge accommodation with async, so you can't say their needs are being dismissed. Why must we break the C in CPython for a use-case that could use one of the GIL-free Pythons?
- semiquaver 3y ago
  The GIL is not held during IO, which is what most web applications and web servers should be spending the vast majority of their time doing. https://docs.python.org/3/library/threading.html https://docs.python.org/3/library/threading.html If that’s too limiting, preforking and other forms of process-based parallelism are a tried and true approach that has been used for years to run python, ruby, PHP, and once upon a time Perl web applications at enormous scale. The difference between threads and processes on Linux is relatively minor. Saying that python doesn’t work for web application use cases because of the GIL is frankly sort of bizarre given the large number of python web applications in the wild chugging along delivering value.
  - jrochkind1 3y ago
    > The GIL is not held during IO, which is what most web applications and web servers should be spending the vast majority of their time doing. While this has been oft-repeated for years, more or less language-independently, I have become convinced it no longer accurately describes ruby on rails apps. People still say it about ruby/rails too though. But my rails web apps are spending 50-80% of their wall time in cpu, rather than blocking on IO. Depending on app and action. And whenever I ask around for people who have actual numbers, they are similar -- as long as they are projects with enough developer experience to avoid things like n+1 ORM problems. I don't have experience with python, so I can't speak to python. but python and ruby are actually pretty similar languages, including with performance characteristics, and the GIL. Python projects tend to use more stuff that's in C, which would make more efficient use of CPU, so that could be a difference. (Also not unrelated to what we're talking about!) But I have become very cautious of accepting "most web applications are spending the vast majority of their time on io blocking rather than CPU" as conventional wisdom without actually having any kind of numbers. vast majority? I would doubt it, but we need empirical numbers.
    - zarzavat 3y ago
      But are they CPU limited? There’s a difference between spending most of your time in CPU, and being CPU limited. If I’m serving 10 requests/second then even if I’m 90% CPU and 10% IO, it doesn’t matter because I’m 99% idle. My mental model for a very high-interpreter overhead language like Ruby or Python for webdev, is that it is appropriate for sites that don’t see that much absolute interactive traffic. e.g. it’s good for a blog where you can put a cache in front of it, or an intranet service where you control the number of users. I would never use Python for a fully interactive high traffic service sitting on the open internet. There are languages that are much better at that.
- stinos 3y ago
  That's somewhat out of context. With the bit you quoted I meant "sure working around the GIL by implemening a web server in that particular way is annoying". I'm not saying that "web server" as a whole is not important or not widely applicable, merely that amongst all other usecases and applications of Python out there, web servers are just one of many. And the particular implementation stated like "10 different deploys" is even a subset of that 'one' and as explained by fellow comments, probably not the most appropriate one.
Fiahil 3y ago
I think Data Scientists would like a word with you. They have plenty of time since their parallel pipeline was OOMKilled.

paulddraper 3y ago

Other languages do that: JavaScript, PHP, Erlang. Python multiprocessing is pretty usable. I like multithreading, but also...it has more footguns then the rest of programming combined. [1] I'm not convinced Python's approach is that bad in practice. [1] https://news.ycombinator.com/item?id=22165193 https://news.ycombinator.com/item?id=22165193

deleted 3y ago
[deleted]
mohaine 3y ago
It is, until the GIL bites you in the ass. As it is you get different behavior if your call is calling out to external code vs being pure python. Note that you really don't know if a random function call is python or wrapping external class so you really get random behavior. The time it got me was a thread just to timeout another process. Tests worked great but the timeout didn't work in production because the call it was wrapping was calling out to C code so nothing would run until the call returned. We even still got the timeout error in the logs and it looked like it was working (it even tossed the now waited for valid results), but not at the time of the timeout but after the call finally returned a few hours later.
- paulddraper 3y ago
  So.... It would have been better if GIL were even more aggressive?

ActorNightly 3y ago

The other languages are not saner. You are basically saying "Python GIL is annoying because I can't write parallel processing performant code in Python". Python has never been and is not a performant language. Its designed for rapid and easy development. The multiprocessing+asyncio in Python fulfills the aspect of utilizing all the resources, albeit at a higher memory cost, but memory is dirt cheap these days. You have a master process and then worker threads. For all things that you would write in Python, where in >90% cases you are network latency limited, the paradigm of a master process and worker processes with IPC on unix sockets works extremely well. Set up a web app with fast api/gunicorn master/uvicorn workers, and it will be plenty fast enough for anything you do.

oconnor663 3y ago

> you could handle multiple requests at the same time To be fair to Python and the GIL, it's totally capable of parallelizing requests when most of the work is network-bound, which is probably the common case. And when the work is CPU-bound, but the CPU-intensive part is written in C, it's also possible for C to release the GIL. So it's really only "heavy computational work directly in Python" programs that are affected by this. (On the other hand, Python applications do naturally expand to look like this over time...)

slt2021 3y ago

No it is not. If you want to reach peak performance single-threaded app with no locks is the way to go, and work being sharded (not shared) among multiple single-threaded apps. Multi-threaded apps with shared state introduce more complexity, than the performance when compared to multiple single-threaded apps running asyncio event loop. For example LMAX Disruptor

gnulinux 3y ago

This is your opinion, but many disagree. I personally find processes infinitely easier to deal with than thread, it's not even a discussion in my mind. For me, threads are banned from usage, until it's absolutely necessary to do so. When I write code in C++ there are cases where a problem cannot be solved unless threads are used. It's fine to use threads there. For everything else I appeal to either multiprocessing or `async` concurrency.

hgs3 3y ago

> You need to duplicate your process, then pay the price of memory usage ... I believe the implementation of the Python multiprocessing package uses fork() on *nix systems which means memory should be copy-on-write. Processes do have the advantage of being self-contained meaning if one crashes, then it will not take down the entire system. Also, the message passing model can theoretically scale to processes running on separate hardware. Thread's cannot do that.