4 ms·

I've changed my opinion about this after many years. A long time ago IronPython was released which showed that you could build a high performance Python interp

by dekhn 3y ago

I've changed my opinion about this after many years. A long time ago IronPython was released which showed that you could build a high performance Python interpreter that was GIL-free. It had thread-safe containers (so multiple threads could work against the same lists, dictionaries, etc) and in some cases was faster than CPython (it was implemented using CLR and .net) When I saw IronPython I was immediately convinced that CPython should be the same way- already low-cost dual and quad core Intel machines were becoming available and it seemed like core counts were going to increase faster than clock rates. I figured that a small hit to serial performance would be more than acceptable if people could write multithreaded systems in Python, in much the same way as I wrote multithreaded C++. Over time after watching nogil not going anywhere in CPython (the python leadership didn't want to do nogil), with concomitant speedups in the single-processor implementation, along with the increasing use of C++ code that releases the GIL, and seeing that many people just weren't good at multithreaded programming, I have started to conclude that the multithreading/multiprocess in Python today is about the best we can get. That is, instead of having threaded containers and multiple interpreter threads all banging on the same underlying data, it's a lot easier to just use threads as work queues that have minimal interaction with other threads. So that's where I've ended up: some of my code using multiprocessing, typically the Pool or ThreadPool, with the concurrent future API to handle result-gathering, barriers, etc. Other code has an external system that starts many python processes from the command line and waits for those processes to complete. Other code is single-threaded in python and launches C++ cores that launch multiple threads just to return a computational result to python faster. And I think trying to do both gil and nogil interpreters, rather than committing to one or the other, the python leadership will sign us up for untold inconveniences around packaging. We already see this in the move to async and it will only be worse with threading. So sad to say I think sticking to GIL and using the approaches I mentioned above (along with others that work well for concurrent, rather than parallel, computing, like coroutines) is the best thing to do right now and I'm a bit bummed that the leadership signalled their intent to accomodate both.

alfalfasprout 3y ago
You've been able to release GIL for a long time though in the C ABI (and C++ via pybind) and that hasn't removed the need for nogil. The reason is that a single thread can invoke multicore c/c++ code (even calling into specialized accelerators if needed) but having python objects that are shared between threads is extremely clunky. And multiprocessing results in a lot of communication overhead. Worse-- python code cannot proceed in another thread. Mixing python and C++ is very common in ML and scientific computing workloads. > And I think trying to do both gil and nogil interpreters, rather than committing to one or the other, the python leadership will sign us up for untold inconveniences around packaging. We already see this in the move to async and it will only be worse with threading. How has packaging been affected by async? As long as you have a compatible python version what issue do you run into?
- dekhn 3y ago
  boto's migration to async has caused no end of package incompatibility problems for me. So that's really more on the aiobotocore developers than python in that case. https://github.com/aio-libs/aiobotocore/issues/890 https://github.com/aio-libs/aiobotocore/issues/890 OK not a great example but also not worth debating about.
FridgeSeal 3y ago
I think this is an interesting take, and it think people should think about their use of Python in general. I personally think that pythons support for the massively parallel hardware we have is lacking, and the devs are being too slow and disparate to respond, combine that with what is basically subpar tooling around threads and you have people reaching for multiprocessing out of necessity. Off the back of this, should Python just maybe give up on threads entirely? Should it relegate itself to simple-scripting and open the floor to something that can do these things? I’ve personally stopped writing Python for these reasons- apart from “AI stuff” which isn’t something I dabble in anymore, there’s nothing that Python can do anymore that another language can’t do better, just as (if not more) easily, without giving anything up.
- Daishiman 3y ago
  99% of programmers have no real need for massively parallel code or prioritizing paralellism over sheer ease of use and easy access to C libraries. People think parallelism is a huge use case. Despite the fact that a ton of CPU cycles are spent on multicore-compatible code, in practice that's just not what the vast majority of programmers spend their days working on.
  - pdimitar 3y ago
    Your comments contain strongly opinionated assertions without proof. Everything that is a server is profiting massively off of true parallelism. Stuff written in Elixir, Golang and Rust scales much better than the same thing written in Python or Ruby. Me and many other colleagues have seen the before and after in our monitoring systems. Maybe you should instead qualify your comments with "I have carefully and deliberately stayed away from the need to do parallel programming throughout my entire career" and I feel that way your comments would have the necessary context. Otherwise you are misleading less experienced people.
lagt_t 3y ago
Optional Gil was originally discussed in 2022, PEPd in early 2023 and approved for 3.13, What do you mean going nowhere or that leadership didn't want it?
- akubera 3y ago
  I think dekhn means the discussions and attempts at removing the GIL before this current PEP. Here's Guido's thoughts on it from 2007: https://www.artima.com/weblogs/viewpost.jsp?thread=214235 https://www.artima.com/weblogs/viewpost.jsp?thread=214235 and that mentions a fork removing the GIL for Python 1.5 in 1999.
- Dylan16807 3y ago
  Originally?
BlackFly 3y ago
Everyone has heard the multi processing advocacy already. Actor model isn't a perfect answer to all concurrency questions. Some people would prefer a pure python connection pool to pgbouncer.

by dekhn 3y ago

alfalfasprout 3y ago

You've been able to release GIL for a long time though in the C ABI (and C++ via pybind) and that hasn't removed the need for nogil. The reason is that a single thread can invoke multicore c/c++ code (even calling into specialized accelerators if needed) but having python objects that are shared between threads is extremely clunky. And multiprocessing results in a lot of communication overhead. Worse-- python code cannot proceed in another thread. Mixing python and C++ is very common in ML and scientific computing workloads. > And I think trying to do both gil and nogil interpreters, rather than committing to one or the other, the python leadership will sign us up for untold inconveniences around packaging. We already see this in the move to async and it will only be worse with threading. How has packaging been affected by async? As long as you have a compatible python version what issue do you run into?

dekhn 3y ago
boto's migration to async has caused no end of package incompatibility problems for me. So that's really more on the aiobotocore developers than python in that case. https://github.com/aio-libs/aiobotocore/issues/890 https://github.com/aio-libs/aiobotocore/issues/890 OK not a great example but also not worth debating about.

FridgeSeal 3y ago

I think this is an interesting take, and it think people should think about their use of Python in general. I personally think that pythons support for the massively parallel hardware we have is lacking, and the devs are being too slow and disparate to respond, combine that with what is basically subpar tooling around threads and you have people reaching for multiprocessing out of necessity. Off the back of this, should Python just maybe give up on threads entirely? Should it relegate itself to simple-scripting and open the floor to something that can do these things? I’ve personally stopped writing Python for these reasons- apart from “AI stuff” which isn’t something I dabble in anymore, there’s nothing that Python can do anymore that another language can’t do better, just as (if not more) easily, without giving anything up.

Daishiman 3y ago
99% of programmers have no real need for massively parallel code or prioritizing paralellism over sheer ease of use and easy access to C libraries. People think parallelism is a huge use case. Despite the fact that a ton of CPU cycles are spent on multicore-compatible code, in practice that's just not what the vast majority of programmers spend their days working on.
- pdimitar 3y ago
  Your comments contain strongly opinionated assertions without proof. Everything that is a server is profiting massively off of true parallelism. Stuff written in Elixir, Golang and Rust scales much better than the same thing written in Python or Ruby. Me and many other colleagues have seen the before and after in our monitoring systems. Maybe you should instead qualify your comments with "I have carefully and deliberately stayed away from the need to do parallel programming throughout my entire career" and I feel that way your comments would have the necessary context. Otherwise you are misleading less experienced people.

lagt_t 3y ago

Optional Gil was originally discussed in 2022, PEPd in early 2023 and approved for 3.13, What do you mean going nowhere or that leadership didn't want it?

akubera 3y ago
I think dekhn means the discussions and attempts at removing the GIL before this current PEP. Here's Guido's thoughts on it from 2007: https://www.artima.com/weblogs/viewpost.jsp?thread=214235 https://www.artima.com/weblogs/viewpost.jsp?thread=214235 and that mentions a fork removing the GIL for Python 1.5 in 1999.
Dylan16807 3y ago
Originally?

BlackFly 3y ago

Everyone has heard the multi processing advocacy already. Actor model isn't a perfect answer to all concurrency questions. Some people would prefer a pure python connection pool to pgbouncer.