<div>In toy examples like this it will be generally hard to convince GHC not to just collapse your program down to a constant, when you're turning up the optimization level. </div><div><br></div><div>In particular, you are implying -ffull-laziness with -O (or -O2), which can increase sharing.</div>
<div><span style="font-family:sans-serif;font-size:medium;background-color:rgb(255,255,255)"><br></span></div><div><span style="background-color:rgb(255,255,255)">> </span><span style="font-family:sans-serif;font-size:medium;background-color:rgb(255,255,255)">GHC doesn't implement complete full-laziness. When optimisation in on, and </span><code class="option" style="background-color:rgb(255,255,255)">-fno-full-laziness</code><span style="font-family:sans-serif;font-size:medium;background-color:rgb(255,255,255)"> is not given, <b>some transformations that increase sharing are performed, such as extracting repeated computations from a loop</b>. These are the same transformations that a fully lazy implementation would do, the difference is that GHC doesn't consistently apply full-laziness, so don't rely on it.</span></div>
<div><br></div><div><a href="http://www.haskell.org/ghc/docs/latest/html/users_guide/options-optimise.html">http://www.haskell.org/ghc/docs/latest/html/users_guide/options-optimise.html</a></div><div><br></div><div>If you explicitly rely on this not happening, turn it off:</div>
<div><br></div><div><div>$ ghc -O2 -fno-full-laziness --make A.hs -rtsopts -fforce-recomp </div><div>[1 of 1] Compiling Main ( A.hs, A.o )</div><div>Linking A ...</div><div><br></div><div>$ time ./A +RTS -M750k</div>
<div>(500000500000,500000500000)</div><div>./A +RTS -M750k 0.06s user 0.00s system 97% cpu 0.069 total</div></div><div><br></div><div>A 750k heap should be enough for anyone :)</div><div><br></div><div>-- Don<br><br><div class="gmail_quote">
On Sun, Feb 24, 2013 at 5:49 PM, Tom Ellis <span dir="ltr"><<a href="mailto:tom-lists-haskell-cafe-2013@jaguarpaw.co.uk" target="_blank">tom-lists-haskell-cafe-2013@jaguarpaw.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To avoid retaining a large lazy data structure in memory it is useful to<br>
hide it behind a function call. Below, "many" is used twice. It is hidden<br>
behind a function call so it can be garbage collected between uses. That's<br>
good. When compiling with "-O" it seems that GHC 7.4.1 decides to keep it<br>
in memory anyway. That's bad. (I can't read core so I don't know exactly<br>
what's going on). Replacing one of the "many" in "twice" with<br>
"different_many" makes everything fine again.<br>
<br>
Is this considered a bug in GHC? Is it a known bug? It is incredibly<br>
concerning that GHC would perform this kind of pessimisation.<br>
<br>
Tom<br>
<br>
<br>
% cat thunkfail.hs<br>
{-# OPTIONS_GHC -fno-warn-unused-binds #-}<br>
<br>
import Data.List<br>
<br>
million :: Int<br>
million = 10 ^ (6 :: Int)<br>
<br>
many :: () -> [Int]<br>
many () = [1..million]<br>
<br>
different_many :: () -> [Int]<br>
different_many () = [1..million]<br>
<br>
twice :: (Int, Int)<br>
twice = (foldl' (+) 0 (many ()), foldl' (+) 0 (many ()))<br>
<br>
main :: IO ()<br>
main = print twice<br>
<br>
% ghc -fforce-recomp -Wall -Werror -rtsopts thunkfail.hs && ./thunkfail +RTS -M5M<br>
[1 of 1] Compiling Main ( thunkfail.hs, thunkfail.o )<br>
Linking thunkfail ...<br>
(1784293664,1784293664)<br>
<br>
% ghc -O -fforce-recomp -Wall -Werror -rtsopts thunkfail.hs && ./thunkfail +RTS -M5M<br>
[1 of 1] Compiling Main ( thunkfail.hs, thunkfail.o )<br>
Linking thunkfail ...<br>
Heap exhausted;<br>
Current maximum heap size is 5242880 bytes (5 MB);<br>
use `+RTS -M<size>' to increase it.<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div><br></div>