PEP 510 (function specialization) rejected
Hi, I rejected my own PEP 510 "Specialize functions with guards" that I wrote in January 2016: https://github.com/python/peps/commit/c99fb8bf5b5c16c170e1603a1c66a74e93a4ae... "This PEP was rejected by its author since the design didn't show any significant speedup, but also because of the lack of time to implement the most advanced and complex optimizations." I stopped working on my FAT Python project almost one year ago: https://faster-cpython.readthedocs.io/fat_python.html Victor
It takes courage to admit failures like this! I think this is a good call.
It echoes the experiences with Unladen Swallow and Pyston. Despite what
people may think, CPython really isn't slow, given the large set of
constraints on the implementation.
On Tue, Oct 17, 2017 at 1:10 PM, Victor Stinner
Hi,
I rejected my own PEP 510 "Specialize functions with guards" that I wrote in January 2016:
https://github.com/python/peps/commit/c99fb8bf5b5c16c170e1603a1c66a7 4e93a4ae84
"This PEP was rejected by its author since the design didn't show any significant speedup, but also because of the lack of time to implement the most advanced and complex optimizations."
I stopped working on my FAT Python project almost one year ago: https://faster-cpython.readthedocs.io/fat_python.html
Victor _______________________________________________ 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/ guido%40python.org
-- --Guido van Rossum (python.org/~guido)
2017-10-17 22:25 GMT+02:00 Guido van Rossum
It takes courage to admit failures like this! I think this is a good call. It echoes the experiences with Unladen Swallow and Pyston. Despite what people may think, CPython really isn't slow, given the large set of constraints on the implementation.
Oh, I still have a long queue of optimization ideas that I want to try :-) But first, I would like to fix the issue blocking all significant optimizations: make the stable ABI usable to allow to change major CPython design choices without breaking C extensions. https://haypo.github.io/new-python-c-api.html Sadly, I didn't find time yet to write a proper PEP for that. Victor
On 18 October 2017 at 06:25, Guido van Rossum
It takes courage to admit failures like this! I think this is a good call. It echoes the experiences with Unladen Swallow and Pyston.
And Armin Rigo's experience with psyco before that. Despite what people may think, CPython really isn't slow, given the large
set of constraints on the implementation.
Antonio Cuni had a good PyPy presentation at EuroPython indirectly talking about the fact that when folks say "Python is slow", what they often mean is "Many of Python's conceptual abstractions come at a high runtime cost in the reference implementation": https://speakerdeck.com/antocuni/the-joy-of-pypy-jit-abstractions-for-free That means the general language level performance pay-offs for alternative implementations come from working out how to make the abstraction layers cheaper, as experience shows that opt-in ahead-of-time techniques like Cython, vectorisation, and binary extension modules can do a much better job of dealing with the clearly identifiable low level performance bottlenecks (Readers that aren't familiar with the concept may be interested in [1] as a good recent example of the effectiveness of the latter approach). Cheers, Nick. [1] https://blog.sentry.io/2016/10/19/fixing-python-performance-with-rust.html -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (3)
-
Guido van Rossum
-
Nick Coghlan
-
Victor Stinner