[Python-Dev] PEP 510 (function specialization) rejected

[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/c99fb8bf5b5c16c170e1603a1c66a74e93a4ae84

"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
Pytho...@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/dev-python%2Bgarchive-30976%40googlegroups.com

[Victor Stinner]

2017-10-17 22:25 GMT+02:00 Guido van Rossum <gu...@python.org>:
> 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.

[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.

Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org

--

--Guido van Rossum (python.org/~guido)

[Nick Coghlan]

On 18 October 2017 at 06:25, Guido van Rossum <gu...@python.org> wrote:

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   |   ncog...@gmail.com   |   Brisbane, Australia