[pypy-dev] Contributing Polyhedral Optimisations in PyPy
muke101 at protonmail.com
Fri Dec 18 13:15:10 EST 2020
For now then I'll try and consider how ambitious replicating these solutions would be and if they would map into PyPy from JS cleanly - please let me know if any other hurdles come to mind in the meantime though.
Thanks again for the advise.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, 18 December 2020 18:03, Armin Rigo <armin.rigo at gmail.com> wrote:
> On Thu, 17 Dec 2020 at 23:48, William ML Leslie
> william.leslie.ttg at gmail.com wrote:
> > The challenge with implementing this in the pypy JIT at this point is
> > that the JIT only sees one control flow path. That is, one loop, and
> > the branches taken within that loop. It does not find out about the
> > outer loop usually until later, and may not ever find out about the
> > content of other control flow paths if they aren't taken.
> Note that strictly speaking, the problem is not that you haven't seen
> yet other code paths. It's Python, so you never know what may happen
> in the future---maybe another code path will be taken, or maybe
> someone will do crazy things with `sys._getframe()` or with the
> debugger `pdb`. So merely seeing all paths in a function doesn't
> really buy you a lot. No, the problem is that emitting machine code
> is incremental at the granularity of code paths. At the point where
> we see a new code path, all previously-seen code paths have already
> been completely optimized and turned into machine code, and we don't
> keep much information about them.
> To go beyond this simple model, what we have so far is that we can
> "invalidate" previous code paths at any point, when we figure out that
> they were compiled using assumptions that no longer hold. So using
> it, it would be possible in theory to do any amount of global
> optimizations: save enough additional information as you see each code
> path; use it later in the optimization of additional code paths;
> invalidate some of the old code paths if you figure out that its
> optimizations are no longer valid (but invalidate only, not write a
> new version yet); and when you later see the old code path being
> generated again, optimize it differently. It's all doable, but
> theoretical so far: I don't know of any JIT compiler that seriously
> does things like that. It's certainly worth a research paper IMHO.
> It also looks like quite some work. It's certainly not just "take
> some ideas from [ahead-of-time or full-method] compiler X and apply
> them to PyPy".
> A bientôt,
More information about the pypy-dev