On Sun, Mar 24, 2019 at 4:22 PM Mark Shannon <m...@hotpy.org> wrote: > > Hi Petr, > > Regarding PEPs 576 and 580. > Over the new year, I did a thorough analysis of possible approaches to > possible calling conventions for use in the CPython ecosystems and came > up with a new PEP. > The draft can be found here: > https://github.com/markshannon/peps/blob/new-calling-convention/pep-9999.rst > > I was hoping to profile a branch with the various experimental changes > cherry-picked together, but don't seemed to have found the time :( > > I'd like to have a testable branch, before formally submitting the PEP, > but I'd thought you should be aware of the PEP. > > Cheers, > Mark.
Hello Mark, Thank you for letting me know! I wish I knew of this back in January, when you committed the first draft. This is unfair to the competing PEP, which is ready and was waiting for the new govenance. We have lost three months that could be spent pondering the ideas in the pre-PEP. Do you think you will find the time to piece things together? Is there anything that you already know should be changed? Do you have any comments on [Jeroen's comparison]? The pre-PEP is simpler then PEP 580, because it solves simpler issues. I'll need to confirm that it won't paint us into a corner -- that there's a way to address all the issues in PEP 579 in the future. The pre-PEP claims speedups of 2% in initial experiments, with expected overall performance gain of 4% for the standard benchmark suite. That's pretty big. As far as I can see, PEP 580 claims not much improvement in CPython, but rather large improvements for extensions (Mistune with Cython). The pre-PEP has a complication around offsetting arguments by 1 to allow bound methods forward calls cheaply. I fear that this optimizes for current usage with its limitations. PEP 580's cc_parent allows bound methods to have access to the class, and through that, the module object where they are defined and the corresponding module state. To support this, vector calls would need a two-argument offset. (That seems to illustrate the main difference between the motivations of the two PEPs: one focuses on extensibility; the other on optimizing existing use cases.) The pre-PEP's "any third-party class implementing the new call interface will not be usable as a base class" looks quite limiting. [Jeroen's comparison]: https://mail.python.org/pipermail/python-dev/2018-July/154238.html _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
