[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