[Python-ideas] Performance improvements via static typing

[Brett Cannon]

On Fri, Jul 20, 2018, 02:33 Stefan Behnel, <stefan_ml at behnel.de> wrote:

> Michael Hall schrieb am 19.07.2018 um 15:51:
> > While I am aware of projects like Cython and mypy, it seems to make sense
> > for CPython to allow optional enforcement of type hints, with compiler
> > optimizations related to it to be used. While this would not receive the
> > same level of performance benefits as using ctypes directly, there do
> > appear to be various gains available here.
>
> Well, first of all, a C level type check at runtime is quite fast compared
> to a byte code dispatch with stack argument handling, and can be done
> regardless of any type hints. There are various code patterns that would
> suggest a certain type ("x.append()" probably appends to a list, "x.get()"
> will likely be a dict lookup, etc.), and that can be optimised for without
> static type declarations and even without any type hints.
>
> Then, the mere fact that user code says "a: List" does not help in any way.
> Even "a: list" would not help, because any behaviour of that "list" might
> have been overridden by the list subtype that the function eventually
> receives.
>
> The same applies to "x: float". Here, in order to gain speed, the compiler
> would have to generate two separate code paths through the entire function,
> one for C double computations, and one for Python float subtypes. And then
> exponentiate that by the number of other typed arguments that may or may
> not contain subtypes. Quite some overhead.
>
> It's unclear if the gain would have any reasonable relation to the effort
> in the end. Sure, type hints could be used as a bare trigger for certain
> optimistic optimisations, but then, it's cheap enough to always apply these
> optimisations regardless, via a C type check.
>

I'll also mention that my masters thesis disproved the benefit of
type-specific opcodes for CPython:
https://scholar.google.com/scholar?cluster=2007053175643839734&hl=en&as_sdt=0,5&sciodt=0,5

What this means is someone will have to demonstrate actual performance
benefits before we talk about semantic changes or modifying the
interpreter. IOW don't prematurely optimize for an optimization until it's
actually been proven to be an optimization. 😉


> Stefan
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180721/9bb3ae44/attachment.html>