#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 daniel.is.fischer): Replying to [comment:8 nh2]:
I have updated the gist at https://gist.github.com/nh2/11333427 to contain both the matmult example (where the difference between `forM_` and `loop` is big) and the simple example (where no difference can be measured).
The simple example doesn't use the same list in different places, so GHC is capable of eliminating it and giving you a loop on unboxed `Int#`s, at least with `-O2`. In the matmult example, you need to conceal the fact that both lists are the same from GHC to get a loop on unboxed `Int#`s. So in principle, GHC can do the desired thing, just the sharing gets in the way. Can somebody think of a situation where sharing is beneficial for `forM_ [a .. b] $ \n -> do ...` code? If not, perhaps special-casing `enumFromTo` arguments for `forM_` etc. is, at least for standard integer types, something to be considered. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8763#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler