On 2020-09-01, Larry Hastings wrote: > Personally I think the future of CPython is to change completely > over to tracing garbage collection. It's so much friendlier to > multicore, which is clearly the future of programming. I'd rather > see efforts in this area directed towards that goal.
I think either CPython does that or some other implementation is going to displace it. CPython doesn't have a good way of utilizing multi-core CPUs. The various multi-process approaches don't solve the problem of efficiently passing data between threads of execution. An elegant approach would be to use message passing like is done by Erlang. However, given that Python is not a functional language and that most core data structures are mutable, it seems a poor fit. The most obvious approach is to adopt a multi-threaded model like is done by modern Java. I.e. no GIL and non-thread safe core data structures. That sounds a bit scary but based on Java experience it seems programmers can manage it. If it wasn't for CPython's reference counted GC, that kind of threading model seems relatively easy to implement. Getting libgc working would be a useful first step: https://discuss.python.org/t/switching-from-refcounting-to-libgc/1641 I guess it's hard to get people excited about that work because you have to go backwards in performance before you can possibily go forward. The non-reference counted CPython is going to be much slower and recovering that performance will be a long slog. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/VBBPHP3FNJQHJLLESO2BTUFJ63H5KSS5/ Code of Conduct: http://python.org/psf/codeofconduct/
