Hi Richard,
On 31 January 2015 at 10:51, Richard Plangger <r...@pasra.at> wrote:
> By using the PEP 484 proposal I think this opens up new possibilities.
The short answer is - no, it doesn't make sense. User-supplied type
annotations wouldn't help at all if they must still be checked, like
PEP 484 says. Or, assuming you're fine with obscure crashes when the
type annotations are wrong, you would get at most extremely minor
speed benefits.
There are several reasons for why. One of them is that annotations
are at the wrong level (e.g. a PEP 484 "int" corresponds to Python 3's
int type, which does not necessarily fits inside one machine word;
even worse, an "int" annotation allows arbitrary int subclasses).
Another is that a lot more information is needed to produce good code
(e.g. "this `f()` called here really means this function there, and
will never be monkey-patched" -- same with `len()` or `list()`, btw).
The third reason is that some "guards" in PyPy's JIT traces don't
really have an obvious corresponding type (e.g. "this dict is so far
using keys which don't override `__hash__` so a more efficient
implementation was used"). Many guards don't even any correspondence
with types at all ("this class attribute was not modified"; "the loop
counter did not reach zero so we don't need to release the GIL"; and
so on).
In summary, as PyPy works right now, it is able to derive far more
useful information than can ever be given by PEP 484, and it works
automatically. As far as we know, this is true even if we would add
other techniques to PyPy, like a fast first-pass method JIT. This
should be obvious from the fact that many high-performance JavaScript
VMs are method JITs too, and they work very well on source code with
no explicit types either. In my opinion, the introductory sentence in
that PEP is a lie: "This PEP aims to provide (...) opening up Python
code to (...) performance optimizations utilizing type information."
This doesn't mean the performance of PyPy is perfectly optimal today.
There are certainly things to do and try. One of the major ones (in
terms of work involved) would be to add a method-JIT-like approach
with a quick-and-dirty initial JIT, able to give not-too-bad
performance but without the large warm-up times of our current
meta-tracing JIT. More about this or others in a later e-mail, if
you're interested.
A bientôt,
Armin.
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
