: ------------------------------------------------------------------
: -- 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 ?
My findings (sun/solaris ghc2.0699999999999998) are different.
Profiled all with +RTS -hC -i0.05: -RTS
+------------------------+-----------------+
| -prof -caf-all -O | -prof -caf-all |
+------------------------+-----------------+
| P1 50K heep | 75K heap |
| P2 55K heap | 75K heap |
| P3 55K heap | 75K heap |
+------------------------+-----------------+
All profiled -O versions are equally fast (+/- 2.8 sec).
The non-profiled -O versions are equally fast as well (+/- 2.3 sec).
Regards,
Marc van Dongen
