[NSWI131] Mozny projekt/thesis pro zajemce o performance

[Petr Tuma]

Dobry den,

shodou okolnosti se nam naskytla moznost podilet se na zajimavem projektu relevantnimu k vyhodnocovani vykonnosti, tedy posilam, pokud by nekoho zajimalo - jde o nastroj pomahajici hledat duvody zmeny vykonu v prekladaci, viz popis nize. Pokud jste sikovna/sikovny a meli byste zajem, dejte mi vedet ? (Zadani je zhruba rozmeru diplomky ale da se z nej udelat i pulrocni full time staz v Oracle Labs Zurich.)

Petr Tuma

---

     Graal Compiler Transformation Bisection Tool
     ------------------------------------------------------------

Changes to the Graal compiler's optimization passes often incur performance impacts on various benchmarks. Very often it is hard to analyze and find the questionable transformation and compilation unit responsible for a performance implication.

This project should create a transformation bisection tool that helps graal compiler developers to diagnose potential performance problems introduced by varying optimization decisions in different versions of the graal compiler.

A typical scenario is there are 2 revisions good and bad:
- Bad changes a heuristic/optimization to make a different decision.
- However, the transformation is buried under a complex profile.
- A typical answer that would help the developer would be:
     revision "bad" changed optimization in x% hot compilation unit foo to not unroll a loop/unroll a loop/etc.
- The developer can then use -Dgraal.ExcludeCompilation filtering to find out if this causes the performance change (locally or in the gate actually with an experiment PR). However, given the vast amount of optimizations * hot compilation units * recompilations * repeated application of optimizations makes this very hard to do by hand.

For this to be automatable we need a few things

- What is hot --> solved by Graal's proftool
- What is optimized in the hot compilations
- We need an optimization log that tracks all major optimizations in a unified way that can be enabled with our scoping infrastructure --> TODO
- What differs in the optimization log --> TODO
- Tooling to understand the log and differences in it -> TODO this project

Steps of the project

          Create optimization log (similar-ish to the inlining log) that, for each larger graal transformation adds unified logging to the optimizations
             Which optimizations to log (initially)
                 Inlining
                 PEA
                 Conditional Elimination
                 Peeling
                 Spec Guard Movement
                 ...
             What to log
                 Compilation unit
                 Compilation identifier
                 Tier
                 Optimization phase
                 Nodes/Loops involved (by ID) + next framestate (after/before/both if necessary)
         Create mx logic that uses proftool to create a optimization log for the hottest n compilation units
         Create mx logic to use (2) to create a summary of proftool + hottest method logs for a commit revision
         Create logic to compare the optimization log + proftool hottest methods for 2 different experiments (different commit revisions in the future)
         Create mx (or bash?) logic to use (4) in a git bisect scenario to find "bad" commits that
             Introduced a transformation in a particular version in the proftool derived methods
             Removed a transformation in a particular version in the proftool derived methods
             Changed the order of proftool hot methods
             Removed methods from proftool hot methods
             Added methods to proftool hot methods
         Integrate into a graal transformation bisection to find commits causing vastly different opt decisions on a workload between 2 commits

-- 
Petr Tuma
Distributed and Dependable Systems
Faculty of Mathematics and Physics
Charles University, Czech Republic
       http://d3s.mff.cuni.cz