[pypy-dev] PyPy improving generated machine code

[Richard Plangger]

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 <rich at 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.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150131/a9d252a6/attachment-0001.sig>