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

[GHC]

#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 lukemaurer):

 Replying to [comment:2 bgamari]:
 > I'm actually not sure that the effect on compiler performance is all
 that modest, unfortunately.
 [[https://perf.haskell.org/ghc/#revision/8d5cf8bf584fd4849917c29d82dcf46ee75dd035|Gipeda]]
 shows that the build time for GHC itself went up by 13%. While some
 increase is to be expected, this is quite significant. Are there any
 obvious knobs that could be adjusted to reduce the amount of work that the
 join point analysis/simplifier do under `-O1`?  The full analysis is great
 for `-O2`, but I do fear that users will be up in arms if the GHC
 regression is representative of user code.

 There isn't anything obvious—the occurrence analyser looks for join points
 as it goes, and that process should only be a small constant overhead.
 Nothing in the simplifier (or elsewhere that I can think of) has to work
 particularly hard to handle join points (or it shouldn't, anyway!).

 > Also, strangely enough, while the join points work eliminated all
 allocations from `fannkuch-redux`, the actual runtime of this test might
 have actually gone up by 8%. I say "might have" since runtime measurements
 are notoriously unstable, but it does look likely that this is a real
 regression: the test's runtime is quite long (4 seconds) and 8% is quite a
 large change. Even if this measurement were off by a factor of two we
 would want to understand it. Can you shed any light on this, Luke?

 I haven't seen that jump before, and it's not obvious why it would happen.
 A quick diff of the dumps shows that the two versions end up with wildly
 different code, so it may be hard to pin any particular culprit.

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