could anybody help me to understand the following small benchmark
for ghc-2.08:
------------------------------------------------------------------
-- Illustration for the "lazy" lists.
--
-- Infinite list of primes - NOT very efficient:
primes' = sieve [2..] :: [Int]
where
sieve (p:ns) = p: (sieve (filter (\n->(mod n p)/=0) ns))
main =
let n = 1000
in
putStr (shows (primes'!!(n+1)) "\n") --(P1)
--putStr (shows (primes'!!n, primes'!!(n+1)) "\n") --(P2)
--putStr
-- (shows (primes'!!n, primes'!!(n+1), primes'!!(quot n 2))
-- "\n"
-- ) --(P3)
------------------------------------------------------------------
How much should differ in the running time the variants (P1),(P2),
(P3) ?
In ghc-2.08 linux, - binary snapshot by Sven Panne -
PC-486, 120MHz, `time ./run +RTS -H4m' it costs:
`ghc -c -O Main.hs' `ghc -c'
(P1): 7933 --p(n+1) 6.5 9.1
(P2): (7927,7933) --p(n),p(n+1) 9.1 9.3
(P3): (7927,7933,3581) --p(n),p(n+1),p(n/2) 9.1 9.2
The column for the `ghc -c' compilation looks natural: the costs of
(Pi) are all the same.
Because the (!!) function invocates not more than 3 times, and this
costs much cheaper than the whole program. Further, the first (n+1)
values in primes' needed in (P2) for the first component of the
pair also participate in the evaluation of the second component.
The interpreter re-uses these values.
I expect this is the evaluation principle in ghc - right?
But why (P2)-c-O differs so much from (P1)-c-O ?
Thank you in advance.
------------------
Sergey Mechveliani
[EMAIL PROTECTED]
