[GHC] #8766: length [Integer] is twice as slow but length [Int] is 10 times faster
GHC
ghc-devs at haskell.org
Mon Mar 10 10:10:13 UTC 2014
#8766: length [Integer] is twice as slow but length [Int] is 10 times faster
--------------------------------------------+------------------------------
Reporter: George | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 7.8.1
Component: Compiler | Version: 7.8.1-rc1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: Runtime performance bug | Unknown/Multiple
Test Case: T8755 | Difficulty: Unknown
Blocking: | Blocked By:
| Related Tickets:
--------------------------------------------+------------------------------
Changes (by nomeata):
* owner: nomeata =>
* status: closed => new
* resolution: fixed =>
Comment:
Hmm, this is not fully fixed, it seems. Consider
{{{
f :: Integer -> Integer
f n = n
{-# NOINLINE f #-}
main :: IO ()
main = sum (map f [0 .. 10000]) `seq` return ()
}}}
Here, the rule
{{{
{-# RULES
"enumDeltaToInteger1" [0] forall c n x . enumDeltaToIntegerFB c n x 1 =
up_fb c n x 1
#-}
}}}
does not fire and we end up with
{{{
main3 :: Integer -> Integer
main3 =
enumDeltaToIntegerFB
@ (Integer -> Integer) main6 (id @ Integer) main2 main5 main4
main5 :: Integer
main5 = __integer 1
}}}
and that despite that we have this code in `Phase = 0`:
{{{
enumDeltaToIntegerFB
@ (Integer -> Integer)
(\ (x :: Integer) (ys [OS=OneShot] :: Integer -> Integer) ->
let {
ds [OS=ProbOneShot] :: Integer
ds = f x } in
\ (ds2 :: Integer) -> ys (plusInteger ds2 ds))
(id @ Integer)
(__integer 0)
(__integer 1)
(__integer 10000)
(__integer 0)
}}}
The rule engine is still a bit of a mystery to me. Why does the rule not
match reliably here?
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8766#comment:14>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list