5 ms·

Single threaded performance is still more important than multi-threaded. Most applications are single threaded, and single threaded programs are much easier to

Single threaded performance is still more important than multi-threaded. Most applications are single threaded, and single threaded programs are much easier to write and debug. Removing the GIL from python will not change that. If no-GIL has a 10% single thread performance hit, that means that essentially all my existing python code would be that much worse.

hospitalJail 3y ago
Are your current python programs slow and it matters? Why havent you implemented multithreading? (don't get me wrong, I know the cost of implementation, but if speed matters, multithreading is a very reasonable step in python)
- birdyrooster 3y ago
  Because the GIL and also you have to use tons of locks to get around the lack of thread safety for pythons objects.
  - deleted 3y ago
    [deleted]
- Spivak 3y ago
  > Why haven't you implemented multi-threading? Because that makes programs slower in Python. Multi-threading in Python is for when you need time-slicing for CPU intensive tasks so that they don't block other work that needs to be be done.
  - coldtea 3y ago
    His point remains, he just phrased it badly. We haven't you implemented a multiprocess pool?
    - gpderetta 3y ago
      Because not everything is trivially parallelizable and multiprocess makes it harder to share data?
      - coldtea 3y ago
        >Because not everything is trivially parallelizable A lot of things are though...
    - munch117 3y ago
      Because it's a global solution to a local problem. With threads, I can encapsulate the use of threads in a class, whose clients never even notice that threads are in use. Sure, threads are a global resource too, but much of the time you can get away with pretending that they're not and create them on demand. Not so with multiprocess. If you use that, then the whole program has to be onboard with it. Threads work great in Python. Well not for maximising multicore performance, of course, but for other things, for structuring programs they're great. Just shuttle work items and results back and forth using queue.Queue, and you're golden - Python threads are super reliable. And if the threads are doing mostly GIL-releasing stuff, then even multicore performance can be good.
      - coldtea 3y ago
        >Not so with multiprocess. If you use that, then the whole program has to be onboard with it Huh? In Python you just need a function to call, and multiprocess will run it wrapped in a process from the pool, while api-wise it would look as it would if it was a threadpool (but with no sharing in the process case, obviously). So what would the rest of the program be onboard with? And all this could also be hidden inside some subpackage within your package, the rest of the program doesn't need to know anything, except to collect the results.
        munch117 3y ago
        multiprocessing needs to run copies of your program that are sufficiently initialised that they can execute the function, yet no initialisation code must be run that should not be run multiple times. That means you either use fork - which is a major can of worms for a reusable library to use. Or you write something like this in your entry point module: if __name__=='__main__': multiprocessing.freeze_support() once_only_application_code() Suppose I don't realise that your library is using multiprocessing, and I carelessly call it from this two-line script: import library_that_uses_multiprocessing_internally library_that_uses_multiprocessing_internally.do_stuff() That's basically a fork bomb. And where do you put the multiprocessing.set_start_method call? Surely not in the library.
vb-8448 3y ago
> If no-GIL has a 10% single thread performance hit, that means that essentially all my existing python code would be that much worse. Maybe in a 100% CPU bound code, most of the code is I/O bound and no one will notice the change, just my opinion.
- burnished 3y ago
  It might be more helpful to think of it in terms of supported use cases, rather than just pure volume.
- wongarsu 3y ago
  Maybe that's just my bubble, but I see much more python in data science projects than in web servers. And in (python) data science even your file reading/writing code quickly gets CPU bound.
  - baq 3y ago
    There was a time like 5-10 years ago where Python was really popular for grassroots web projects. Nowadays this is mostly node looks like.
  - coldtea 3y ago
    Not in pure Python, that's in specialized libs, like numpy, pandas and co, done in C. So, the hit on the Python interpreter wouldn't translate to a hit on those.
  - regularfry 3y ago
    That's going to be CPU-bound in numpy's C extensions rather than Python itself, one would hope. The worst of all worlds is that we get a 10% perf cut to python execution and numpy breaks because the C API is ripped up.
  - gpderetta 3y ago
    That's because you are doing it wrong. You'll need to split every step of your data science pipeline into a microservice, then put it in the cloud for resilience. Then the application will be so fast that it is no longer CPU bound but I/O bound.
coldtea 3y ago
>If no-GIL has a 10% single thread performance hit, that means that essentially all my existing python code would be that much worse. So? Especially since the "Faster Python" team already made Python 1.11 "10–60% Faster than 3.10", and 1.12 is even faster still, whereas their overall plan is to get it to 2-5 times faster compared to 3.9. So at the worst case, with a 10% hit, you'd balance out the 3.11 speed, and your code would be as fast as 3.10.
- shpx 3y ago
  But your software would still run 10% slower than it needs to. Single threaded code is like 99% of all code written.
  - gpderetta 3y ago
    that's not an argument either, as your software is already 10000% slower than it needs to be as you have written it in python.
    - deleted 3y ago
      [deleted]
  - coldtea 3y ago
    >But your software would still run 10% slower than it needs to There's no absolute objective "needs to" or even any static baseline. Python can have, and often has had, a performance regression that drop your code by 10% at any time. It's no big deal in itself. Also consider a further speedup of e.g. 50% in upcoming versions (they have promised more). If you're OK with the X speed of today's Python, you should be ok with X + 40% - even if it's not the X + 50% it could have been due to the 10% GIL's removal toll.

hospitalJail 3y ago

Are your current python programs slow and it matters? Why havent you implemented multithreading? (don't get me wrong, I know the cost of implementation, but if speed matters, multithreading is a very reasonable step in python)

birdyrooster 3y ago
Because the GIL and also you have to use tons of locks to get around the lack of thread safety for pythons objects.
- deleted 3y ago
  [deleted]
Spivak 3y ago
> Why haven't you implemented multi-threading? Because that makes programs slower in Python. Multi-threading in Python is for when you need time-slicing for CPU intensive tasks so that they don't block other work that needs to be be done.
- coldtea 3y ago
  His point remains, he just phrased it badly. We haven't you implemented a multiprocess pool?
  - gpderetta 3y ago
    Because not everything is trivially parallelizable and multiprocess makes it harder to share data?
    - coldtea 3y ago
      >Because not everything is trivially parallelizable A lot of things are though...
  - munch117 3y ago
    Because it's a global solution to a local problem. With threads, I can encapsulate the use of threads in a class, whose clients never even notice that threads are in use. Sure, threads are a global resource too, but much of the time you can get away with pretending that they're not and create them on demand. Not so with multiprocess. If you use that, then the whole program has to be onboard with it. Threads work great in Python. Well not for maximising multicore performance, of course, but for other things, for structuring programs they're great. Just shuttle work items and results back and forth using queue.Queue, and you're golden - Python threads are super reliable. And if the threads are doing mostly GIL-releasing stuff, then even multicore performance can be good.
    - coldtea 3y ago
      >Not so with multiprocess. If you use that, then the whole program has to be onboard with it Huh? In Python you just need a function to call, and multiprocess will run it wrapped in a process from the pool, while api-wise it would look as it would if it was a threadpool (but with no sharing in the process case, obviously). So what would the rest of the program be onboard with? And all this could also be hidden inside some subpackage within your package, the rest of the program doesn't need to know anything, except to collect the results.
      - munch117 3y ago
        multiprocessing needs to run copies of your program that are sufficiently initialised that they can execute the function, yet no initialisation code must be run that should not be run multiple times. That means you either use fork - which is a major can of worms for a reusable library to use. Or you write something like this in your entry point module: if __name__=='__main__': multiprocessing.freeze_support() once_only_application_code() Suppose I don't realise that your library is using multiprocessing, and I carelessly call it from this two-line script: import library_that_uses_multiprocessing_internally library_that_uses_multiprocessing_internally.do_stuff() That's basically a fork bomb. And where do you put the multiprocessing.set_start_method call? Surely not in the library.

vb-8448 3y ago

> If no-GIL has a 10% single thread performance hit, that means that essentially all my existing python code would be that much worse. Maybe in a 100% CPU bound code, most of the code is I/O bound and no one will notice the change, just my opinion.

burnished 3y ago
It might be more helpful to think of it in terms of supported use cases, rather than just pure volume.
wongarsu 3y ago
Maybe that's just my bubble, but I see much more python in data science projects than in web servers. And in (python) data science even your file reading/writing code quickly gets CPU bound.
- baq 3y ago
  There was a time like 5-10 years ago where Python was really popular for grassroots web projects. Nowadays this is mostly node looks like.
- coldtea 3y ago
  Not in pure Python, that's in specialized libs, like numpy, pandas and co, done in C. So, the hit on the Python interpreter wouldn't translate to a hit on those.
- regularfry 3y ago
  That's going to be CPU-bound in numpy's C extensions rather than Python itself, one would hope. The worst of all worlds is that we get a 10% perf cut to python execution and numpy breaks because the C API is ripped up.
- gpderetta 3y ago
  That's because you are doing it wrong. You'll need to split every step of your data science pipeline into a microservice, then put it in the cloud for resilience. Then the application will be so fast that it is no longer CPU bound but I/O bound.

coldtea 3y ago

>If no-GIL has a 10% single thread performance hit, that means that essentially all my existing python code would be that much worse. So? Especially since the "Faster Python" team already made Python 1.11 "10–60% Faster than 3.10", and 1.12 is even faster still, whereas their overall plan is to get it to 2-5 times faster compared to 3.9. So at the worst case, with a 10% hit, you'd balance out the 3.11 speed, and your code would be as fast as 3.10.

shpx 3y ago
But your software would still run 10% slower than it needs to. Single threaded code is like 99% of all code written.
- gpderetta 3y ago
  that's not an argument either, as your software is already 10000% slower than it needs to be as you have written it in python.
  - deleted 3y ago
    [deleted]
- coldtea 3y ago
  >But your software would still run 10% slower than it needs to There's no absolute objective "needs to" or even any static baseline. Python can have, and often has had, a performance regression that drop your code by 10% at any time. It's no big deal in itself. Also consider a further speedup of e.g. 50% in upcoming versions (they have promised more). If you're OK with the X speed of today's Python, you should be ok with X + 40% - even if it's not the X + 50% it could have been due to the 10% GIL's removal toll.