Hi, Even if my idea (PEP 484) does not work out I might still be interested in contributing to PyPy. To decide and get my thesis going I need some more resources I can read (maybe some papers that do it similar what you have in mind) plus some hints to isolate the topic. The method-JIT-like approach sounds interesting.
It would be nice if you could provide more detail on the method-JIT-like
approach and other things that can be done right now to make PyPy
faster. After that I will discuss with my adviser if this is a suitable
topic.
Best,
Richard
On 01/31/2015 03:40 PM, Armin Rigo wrote:
> 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.
>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
