On 2020-06-30 02:46, Victor Stinner wrote:
> You missed the point of the PEP: "It becomes possible to experiment
> with more advanced optimizations in CPython than just
> micro-optimizations, like tagged pointers."
I don't think experiments are a good motivation.
When the C API is broken, everyone that uses it pays the price -- they
have to update their code. They pay the price even if the experiment
fails, or if it's never started in the first place.
Can we treat the C API not as a place for experiments, but as a stable
foundation to build on?
The C API should indeed not be a place to experiment, but the current C API leaks so many implementation details, it becomes impossible to have meaningful experiments with different implementations. For example, the purpose of the experiments I've done is to improve the implementation of Python -- speed, memory use, threading, copy-on-write behaviour in forked processes, etc -- in real world applications, with real-world third-party dependencies. The specific things Victor is aiming to change are an active impediment in those experiments, because I end up having to change a lot of third-party code to be able to build or run the application, and even if I find a beneficial change, I can't actually use it without incurring a massive maintenance burden.
For example, could we only deprecate the bad parts, but not remove them
until the experiments actually show that they are preventing a
beneficial change?
Well, right now we can show that they're impacting the *search* for a beneficial change rather negatively :) And what's worse, it will take many years to actually get rid of the old APIs, so if we do the work only once we have a specific beneficial change, we won't be able to *use* the beneficial change until much, much later.
I would also argue that not leaking implementation details (in the API, not the ABI) makes for much better code all-round.
And yes, there will be beneficial changes that require changing the API that we can't anticipate -- that's fine.
The thing is we can stop leaking implementation details now and make everyone's life easier in the future.
The main matter is the question of the *cost* of these changes, and how we measure it. I agree with Victor that for this purpose, we should measure the run-time cost in meaningful, real-world benchmarks (not micro-benchmarks) in sensibly optimised builds. The impact of using PGO, LTO and no-semantic-interpositioning is so big, it doesn't make sense to care about 5% performance cost if you *aren't* using them.
The cost on developers of CPython and of third-party libraries is a different matter, and something we can surely debate. We should agree on whether the change is of benefit to CPython first, though.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/FVATSACB5QPTZS6YLSH5YCHHODJNBLA6/
Code of Conduct: http://python.org/psf/codeofconduct/