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/

Reply via email to