4 ms·

It may not be very significant in this context. But the author literally starts by explaining that that's a typical argument for webservers because they're mos

• polotics 2y ago
  are you sure though that being more CPU-bound will imply more waiting on the GIL? CPU-bound python in my experience means libraries, like eg. numpy, that are well-designed and release the GIL.
  • fleetfox 2y ago
    If you are interested PEP703 describes the scenarios pretty well: https://peps.python.org/pep-0703/#motivation https://peps.python.org/pep-0703/#motivation
    • johnjr 2y ago
      I just wrote a post about how the Cpython is much faster without GIL:https://news.ycombinator.com/item?id=40988244 https://news.ycombinator.com/item?id=40988244
      • arp242 2y ago
        I mean, only the threaded version, which is expected. For tons of cases Python without the GIL is not just slower, but significantly slower; "somewhere from 30-50%" according to one of the people working on this: https://news.ycombinator.com/item?id=40949628 https://news.ycombinator.com/item?id=40949628 All of this is why the GIL wasn't removed 20 years ago. There are real trade-offs here.
        • BossingAround 2y ago
          How is single-threaded code slower without GIL?
          • pKasdhB 2y ago
            Because in the --disable-gil build data structures like ref-counting, dicts, freelists, etc. are locked, even when there is only a single thread. This is the reason why previous attempts were rejected. But those attempts came from single individuals and not from a photo sharing website. This matters if --disable-gil becomes the default in the future and is forced on everyone.
            • nemetroid 2y ago
              That cannot be the reason for a 30-50% slowdown. Uncontested locks are very fast.
              • krhsG 2y ago
                They may be fast in C++, but not in the context of CPython. Here are the dirty details. Note that fine-grained locking has also been tried before: https://dabeaz.blogspot.com/2011/08/inside-look-at-gil-removal-patch-of.html https://dabeaz.blogspot.com/2011/08/inside-look-at-gil-remov...
                • nemetroid 2y ago
                  Thanks for the link, that's an interesting read. Actually the referenced PyMutex is a good old pthread_mutex_t, the same you'd use in C or C++. But I shouldn't have written so surely. Although uncontested locks are very fast, if the loop is tight enough, adding locks will be significant. However, PEP 703 specifically points out that performance-critical container operations (__getitem__/iteration) avoid locking, so I'm still highly skeptical that those locks are the cause of the 30-50%. https://peps.python.org/pep-0703/#optimistically-avoiding-locking https://peps.python.org/pep-0703/#optimistically-avoiding-lo...
                  • 2y ago
        • rbenchmark 2y ago
          30-50% is an understatement. The latest beta is more than 100% slower in a simple benchmark: https://news.ycombinator.com/item?id=41019626 https://news.ycombinator.com/item?id=41019626
    • deleted 2y ago
      [deleted]
• godelski 2y ago
  > for webservers because they're mostly I/O bound I'm not a web person, but can't you also gain I/O from parallelization? The I/O bound is waiting on responses right? So parallelization should increase I/O because you can make multiple asynchronous requests and even if there is dependence you can often stage or do partial computation in the mean time (at least this is common in scientific computing). (And if disk, well reading/writing to disk in parallel is far faster than serial but idk why you'd read/write to disk with pure python. Though it seems people do). So wouldn't this have significant effects that are more than the 36ms that we see in TFA? Or am I missing something and can someone explain why my guess is wrong?
  • Flimm 2y ago
    The GIL doesn't prevent all types of parallelization. You have always been able to use threads or to use async code to make I/O happen in parallel.