Opened 5 years ago

Last modified 16 months ago

#7511 new bug

Room for GHC runtime improvement >~5%, inlining related

Reported by: danielv Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.6.1
Keywords: Inlining Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Runtime performance bug Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

I compare running nofib under GHC with default optimization flags vs. with somewhat extreme settings to inlining aggressiveness.

  1. Many programs are unaffected, but some are improved significantly. Geometric mean: -6.5% allocs, -5.9% runtime.
  1. Some regress significantly, beyond what the obvious code size growth would explain.
    circsim          +0.7%     -4.5%     -0.7%     -0.9%     +2.1%
    comp_lab_zift    +0.5%     -0.1%     -3.3%     -3.3%    +28.6%
    fulsom          +13.8%     -2.6%     +4.3%     +4.3%    +10.8%
    mandel2          +0.4%     +4.5%      0.01      0.01     +0.0%
    paraffins        +0.5%     +0.0%     +4.0%     +2.9%     +0.0%
    rewrite          +0.4%    +15.9%      0.03      0.03     +0.0%
    tak              +0.1%     +4.0%      0.02      0.02     +0.0%
    treejoin         -0.1%     -0.0%     +2.2%     +1.7%     +0.0%
    wave4main        +1.6%    +29.4%    +19.9%    +19.9%    +30.8%
    

This presents two opportunities:

  1. Find better default flags settings (maybe not quite as extreme) and make them the default.
  1. Find the reasons behind the regressions, and fix them in GHC. In addition to improving the performance we perceive through GHC, hopefully performance will become more predictable to users: Simon PJ has told me he expects (paraphrasing) "more inlining should make things better, except for/through code size", which would be a very useful invariant; the data here clearly show some cases where it does not hold.

Included are a complete report, an extract of the highlights (significantly improved or any regressed benchmarks) and the script to reproduce given a ghc7.6 devel2 build.

Attachments (2)

compareGhc76RegVsVeryKeen.txt (155.5 KB) - added by danielv 5 years ago.
Full report I excerpted from
nofibKeenessCompare (331 bytes) - added by danielv 5 years ago.
Script to produce logs, use nofib/nofib-analyse/nofib-analyse to produce reports.

Download all attachments as: .zip

Change History (11)

Changed 5 years ago by danielv

Full report I excerpted from

comment:1 Changed 5 years ago by danielv

Skipping the highlights since the regressions ended up inline.

Changed 5 years ago by danielv

Attachment: nofibKeenessCompare added

Script to produce logs, use nofib/nofib-analyse/nofib-analyse to produce reports.

comment:2 Changed 5 years ago by nfrisby

Just FYI, I've recently seen one example where more inlining caused an increase in allocation. Here's an abstraction:

f a b = let-no-escape j = ...
        in ... j ...

g x y = ... case f (...) (...) of ...

f got inlined and the j binding got floated out a bit. Thus j was no longer LNE, since the result of its call was scrutinized.

This happened in puzzle; the StateType's == and /= methods were f and g, respectively. I had accidentally awarded a huge result discount to ==. Yell if you'd like more details.

comment:3 Changed 5 years ago by simonpj

Cc: simonpj@… removed
difficulty: Unknown

Right! I think this loss of let-no-escapey-ness is precisely what can cause increased allocation when we inline. Daniel and I found this (hence the birth of this ticket), and I believe that the LNE thing was the sole cause we identified.

One might solve this by making the code generator yet more clever, so that it can avoid allocation for non-escaping functions, even they aren't tail calls. But that is quite hard.

More promising, I think, is to float that j function to top level altogether, and that is what Nick is working on. I'm hopeful that this'll solve much of the problem.

See also #5075 which reports a similar difficulty with LNEs becoming non-LNEs.

comment:4 Changed 5 years ago by igloo

Milestone: 7.8.1

comment:5 Changed 4 years ago by thoughtpolice

Milestone: 7.8.37.10.1

Moving to 7.10.1

comment:6 Changed 3 years ago by thoughtpolice

Milestone: 7.10.17.12.1

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:7 Changed 2 years ago by thoughtpolice

Milestone: 7.12.18.0.1

Milestone renamed

comment:8 Changed 22 months ago by thomie

Milestone: 8.0.1

comment:9 Changed 16 months ago by mpickering

Keywords: Inlining added
Note: See TracTickets for help on using tickets.