[GHC] #13220: Performance regressions in testsuite from join points

GHC ghc-devs at haskell.org
Fri Feb 10 19:12:32 UTC 2017


#13220: Performance regressions in testsuite from join points
-------------------------------------+-------------------------------------
        Reporter:  lukemaurer        |                Owner:  lukemaurer
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.2.1
       Component:  Compiler          |              Version:  8.1
      Resolution:                    |             Keywords:  JoinPoints
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by rwbarton):

 An initial report. I collected timing information from validation builds
 of the "Join points" commit and its parent commit, each built twice using
 ghc-8.0.2 and then a perf build of the same commit as the bootstrapping
 compiler (for reasons to become clear below). I have only looked at the
 timing results for a few modules so far. Here are the times for everyone's
 favorite module, `DynFlags.hs`.

 {{{
 stage1 build: bootstrapped by          mutator CPU seconds
     ghc-8.0.2                             63s
     ghc-HEAD-before-join                  63s
     ghc-HEAD-after-join                   67s
 stage2 build:
     ghc-HEAD-before-join                  150-154s
     ghc-HEAD-after-join                   209-213s
 }}}
 Observations:

 * Performance of the perf build (used as the bootstrapping compiler, for
 the stage1 build of `DynFlags`) may have regressed by a few percent with
 join points. For now this is looking at the time for just one module, so I
 wouldn't take that number very seriously.

 * The time it took the stage1 compiler to perform the stage2 build of
 `DynFlags` increased by around 40% with the join point change. But, these
 numbers are both MUCH larger than the time it took to do the stage1 build
 of `DynFlags`. There are a few possible causes:
   - The stage1 compiler is built with only `-O`, unlike the perf build
 that produced the bootstrapping compiler, which built with `-O2`.
   - The stage1 compiler is built with `-DDEBUG`, so it contains extra
 sanity checks.
   - The stage2 compiler is built with `-dcore-lint`, so additional extra
 checks are being done during the stage2 build.
   - Something else about the build could be different between the two
 stages, like the values of CPP macros. I think this is unlikely to be the
 cause in this case.
  One of these points seems to have gotten much worse with join points.

 The good news is that, according to preliminary results, the performance
 of the perf (i.e., release) build of the compiler seems to be minimally
 affected. And if the performance regression is in `-dcore-lint`, for
 example, it may be easy to track down and eliminate.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13220#comment:14>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler


More information about the ghc-tickets mailing list