> On Jun 29, 2020, at 5:46 PM, Victor Stinner <vstin...@python.org> 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." > > IMHO it's time to stop wasting our limited developer resources on > micro-optimizations and micro-benchmarks, but think about overall > Python performance and major Python internals redesign to find a way > to make Python overall 2x faster, rather than making a specific > function 10% faster.
That is a really bold claim. AFAICT there is zero evidence that this actually possible. Like the sandboxing project, these experiments may all prove to be dead-ends. If we're going to bet the farm on this, there should at least be a proof-of-concept. Otherwise, it's just an expensive lottery ticket. > I don't think that the performance of accessing namedtuple attributes > is a known bottleneck of Python performance. This time you missed the point. Named tuple access was just one point of impact — it is not the only code that calls PyTuple_Check(). It looks like inlining did not work and that EVERY SINGLE type check in CPython was affected (including third party extensions). Also, there was no review — we have a single developer pushing through hundreds of these changes at a rate where no one else can keep up. > Measuring benchmarks which take less than 1 second requires being very > careful. Perhaps you don't want to believe the results, but the timings are careful, stable, repeatable, and backed-up by a disassembly that shows the exact cause. The builds used for the timings were the production macOS builds as distributed on python.org. There is a certain irony in making repeated, unsubstantiated promises to make the language 2x faster and then checking in changes that make the implementation slower. Raymond P.S. What PyPy achieved was monumental. But it took a decade even with a well-organized and partially-funded team of superstars. It always lagged CPython in features. And the results were entirely dependent on a single design decision to run a pure python interpreter written in rpython to take advantage of its tracing JIT. I don't imagine CPython can hope to achieve anything like this. Likely, the best we can do is replace reference counting with garbage collection. _______________________________________________ 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/W3GTCPQCTXH3DMFFNS7KDV5GAHT6XZLJ/ Code of Conduct: http://python.org/psf/codeofconduct/
