> > The Instagram team behind the Cinder project may be interested to > review Mark's work before it's merged into Python development branch. > A design PEP would be more convenient than reviewing an concrete > implementation.
I can't speak for others on the Cinder team, but I would definitely be happy to help review, and a design document would be great for that. I'm certainly curious what the design is for the Microsoft implementation and how it differs from our shadow code implementation. Right now I certainly don't have enough information to know what the differences are. And of course the reason to open source Cinder was to help avoid duplication of effort as obviously there's a lot of interest in making Python faster! So if there's interest in our shadow code implementation I'd be happy to work to break it out into more reviewable pieces as well - it's got some pretty natural ways to split it up. On Thu, May 27, 2021 at 2:21 PM Victor Stinner <vstin...@python.org> wrote: > Hi, > > The gilectomy was mentioned earlier in the thread. This project was > created by a core dev who had the permission to push directly his work > into the development branch, but it was done on a work. > > Another optimization project example was my experimental "FAT Python" > project. The main idea was to specialize functions with some > assumptions, and check these assumptions at the function entry. I > started in a fork and then wrote 3 PEPs to propose to merge the main > changes into Python development branch: > > * PEP 509 -- Add a private version to dict > * PEP 510 -- Specialize functions with guards > * PEP 511 -- API for code transformers > > The PEP 509 was accepted since it could be used for other > optimizations: Python now uses the dictionary version to optimize > LOAD_GLOBAL. > > The two other PEPs were rejected. Even if I was very disappointed when > they were rejected, it seems like it was a wize choice since I was > never able to make Python significantly faster (like 2x faster). It > was only 10-20% faster on some micro-benchmarks. I also had the > permission to push directly, and I think that it was nice to confront > my design and ideas to the community. > > I also understand that optimizing Python is really hard and it > requires a lot of preparation work. It's hard to sell the preparation > work since it only introduces regressions and noise without any > concrete speedup. All of this work is required to implement the real > interesting optimization. Moreover, few people are earger to review a > Python fork with deep and large changes in Python internals. The work > must be re-done step by step with more "atomic" (small) changes to > have a readable Git history. > > The Instagram team behind the Cinder project may be interested to > review Mark's work before it's merged into Python development branch. > A design PEP would be more convenient than reviewing an concrete > implementation. > > Victor > _______________________________________________ > 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/CS7WDQYHJN7QV6TQW3CJZ2XRQRKX2RWT/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ 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/VGEBI3YC5I6ESO7SKZL44A3AGNO5OLFZ/ Code of Conduct: http://python.org/psf/codeofconduct/
