5 ms·

> 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 applicab

by 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.
    - miketheman 3y ago
      > I would never use Python for a fully interactive high traffic service sitting on the open internet. So, nothing like Instagram, Dropbox, or YouTube?
    - jrochkind1 3y ago
      > 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. I get your point I think, but that depends on the capacity of the host you are on, and how much the total amount of CPU is, not just the proportion vs IO. Rails may not be a good comparison to python, perhaps it is especially a CPU hog, but I have definitely seen rails apps for which 90% CPU and 10 rps would saturate the hosts CPU yeah. I mean, the math is--- if you have a 111ms response time, 90% of that was spent on cpu (90% of 111 is 100), and you have 10 requests per second (100ms * 10 == 1 second) -- you are now saturating a single core cpu, right? Those are not crazy numbers. But of course Rails has a GIL too -- so you can be "cpu limited" with spare CPU available on other cores, depending on how you've set things up -- that's the original conversation topic here, right? How the GIL may or may not complicate attempts to make efficient use of resources? For what we're talking about, the issue I guess is whether they would be CPU limited with the GIL but not without the GIL. Which seems plausible. (And of course Rails is very very commonly used "for a fully interactive high traffic service sitting on the open internet" -- so I don't see why python, a language with pretty similar relevant characteristics, couldn't or shouldn't be? Despite having little python experience, the issues with GIL are something very very similar in Ruby/Rails, is why I'm in the conversation) It's easy to start getting confused about what we're talking about here, or be talking about different things at once.
- mlyle 3y ago
  > which is what most web applications and web servers should be spending the vast majority of their time doing. Sure... but if you have dozens of threads spending most of their time doing I/O, that still leaves many threads wanting to do things other than I/O. > The difference between threads and processes on Linux is relatively minor. Except having any shared state between processes is painful. If you're hitting an outside database for everything, it's fine.
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.

by stult 3y ago

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.
  - miketheman 3y ago
    > I would never use Python for a fully interactive high traffic service sitting on the open internet. So, nothing like Instagram, Dropbox, or YouTube?
  - jrochkind1 3y ago
    > 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. I get your point I think, but that depends on the capacity of the host you are on, and how much the total amount of CPU is, not just the proportion vs IO. Rails may not be a good comparison to python, perhaps it is especially a CPU hog, but I have definitely seen rails apps for which 90% CPU and 10 rps would saturate the hosts CPU yeah. I mean, the math is--- if you have a 111ms response time, 90% of that was spent on cpu (90% of 111 is 100), and you have 10 requests per second (100ms * 10 == 1 second) -- you are now saturating a single core cpu, right? Those are not crazy numbers. But of course Rails has a GIL too -- so you can be "cpu limited" with spare CPU available on other cores, depending on how you've set things up -- that's the original conversation topic here, right? How the GIL may or may not complicate attempts to make efficient use of resources? For what we're talking about, the issue I guess is whether they would be CPU limited with the GIL but not without the GIL. Which seems plausible. (And of course Rails is very very commonly used "for a fully interactive high traffic service sitting on the open internet" -- so I don't see why python, a language with pretty similar relevant characteristics, couldn't or shouldn't be? Despite having little python experience, the issues with GIL are something very very similar in Ruby/Rails, is why I'm in the conversation) It's easy to start getting confused about what we're talking about here, or be talking about different things at once.
mlyle 3y ago
> which is what most web applications and web servers should be spending the vast majority of their time doing. Sure... but if you have dozens of threads spending most of their time doing I/O, that still leaves many threads wanting to do things other than I/O. > The difference between threads and processes on Linux is relatively minor. Except having any shared state between processes is painful. If you're hitting an outside database for everything, it's fine.

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.