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

GHC ghc-devs at haskell.org
Sun Feb 9 22:07:49 UTC 2014


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

Comment (by nh2):

 People on #ghc think that it is because the {{{[1.._N]}}} gets floated out
 as a top-level constant expression:


 ----


 '''nomeata:''' nh2: I’d consider that a bug
 '''nomeata:''' I believe the problem is that [0..512] does not depend on
 any local values
 '''nomeata:''' so it is floated out as a top-level value
 '''nomeata:''' and there it is not matched by any rules
 '''thoughtpolice:''' let floating strikes again
 '''thoughtpolice:''' (well, floating-out being a non-optimization,
 anyway.)
 '''Fuuzetsu:''' does this mean that if I use [0 .. 512] twice in a program
 in different places, it will only be computed once?
 '''hvr:''' Fuuzetsu: there's a chance, yes
 '''Fuuzetsu:''' neat
 '''thoughtpolice:''' well, not so neat. in cases like this you really
 don't want to float out some things, because it hurts later opportunities
 to optimize sometimes (e.g. float out a binding that otherwise would have
 triggered a RULE or fusion, perhaps)
 '''thoughtpolice:''' unfortunately floating like this is one of the harder
 things to 'fight against' when you don't want it, from what i've seen.

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


More information about the ghc-tickets mailing list