[GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function)

GHC ghc-devs at haskell.org
Fri Apr 20 11:27:47 UTC 2018


#8763: forM_ [1..N] does not get fused (10 times slower than go function)
-------------------------------------+-------------------------------------
        Reporter:  nh2               |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.6.1
       Component:  Compiler          |              Version:  7.6.3
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Runtime           |  Unknown/Multiple
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #7206             |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by sgraf):

 Replying to [comment:61 simonpj]:
 > Looks plausible to me, but needs a careful Note to explain the issues.
 >
 > But before we go too far with this, I'd like to point to
 [wiki:LateLamLift late lambda lifting].  In the core reported in
 comment:44, all we need to do is lambda-lift `$wc` and `go_up` to top
 level, and all will be well, I claim.  And that is precisely what late-
 lambda lifting does.  And the result might be faster than the very careful
 code above, because of the extra argument passing and case-tesing it has
 to do.
 >
 > To me LLF is low-hanging fruit. There are promising results described on
 the wiki page, and the whole join-point business eliminates its principal
 shortcoming.
 >
 > I wonder if, before going ahead with this somewhat-delicate `efdtIntFB`
 business, it might be fun to re-awaken LLF?

 I'll give it a try. Without understanding all operational consequences of
 LLF, I'd still guess that making sure all `c`s inline would be more
 beneficial in this scenario.

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


More information about the ghc-tickets mailing list