<div dir="ltr">JHC compiles to C and last time I tried this it looked very much like the original C version: <a href="http://www.reddit.com/r/haskell/comments/1bcru7/damn_lies_and_haskell_performance/c9689a3">http://www.reddit.com/r/haskell/comments/1bcru7/damn_lies_and_haskell_performance/c9689a3</a><div>

<br></div><div>This is the same thing. Compile with --tdir=/tmp/ajhc and then cat /tmp/ajhc/main_code.c. Output should be like this:<div><br></div><div><div>static uint32_t A_STD</div><div>fW$__fMain_1__ack(gc_t gc,uint32_t v105553376,uint32_t v61835120)</div>

<div>{</div><div>        if (0 == v105553376) {</div><div>            return 1 + v61835120;</div><div>        } else {</div><div>            uint32_t v16;</div><div>            uint32_t v22;</div><div>            struct tup1 x2;</div>

<div>            if (0 == v61835120) {</div><div>                uint32_t v228308038 = (v105553376 - 1);</div><div>                x2.t0 = v228308038;</div><div>                x2.t1 = 1;</div><div>            } else {</div>

<div>                uint32_t v110947990;</div><div>                uint32_t v215884490 = (v61835120 - 1);</div><div>                uint32_t v62470112 = (v105553376 - 1);</div><div>                v110947990 = fW$__fMain_1__ack(gc,v105553376,v215884490);</div>

<div>                x2.t0 = v62470112;</div><div>                x2.t1 = v110947990;</div><div>            }</div><div>            v22 = x2.t0;</div><div>            v16 = x2.t1;</div><div>            return fW$__fMain_1__ack(gc,v22,v16);</div>

<div>        }</div><div>}</div></div><div><br></div><div style>And it&#39;s as fast as C on my machine:<br><br></div><div style><div>chris@midnight:~/Projects/me/ajhc$ time ./ack</div><div>65533</div><div><br></div><div>

real<span class="" style="white-space:pre">        </span>0m2.134s</div><div>user<span class="" style="white-space:pre">        </span>0m2.124s</div><div>sys<span class="" style="white-space:pre">        </span>0m0.000s</div><div>chris@midnight:~/Projects/me/ajhc$ gcc -O3 ack.c -o ack-c</div>

<div>ack.c: In function ‘main’:</div><div>ack.c:8:3: warning: incompatible implicit declaration of built-in function ‘printf’ [enabled by default]</div><div>chris@midnight:~/Projects/me/ajhc$ time ./ack-c</div><div>65533</div>

<div><br></div><div>real<span class="" style="white-space:pre">        </span>0m2.255s</div><div>user<span class="" style="white-space:pre">        </span>0m2.248s</div><div>sys<span class="" style="white-space:pre">        </span>0m0.000s</div>

<div>chris@midnight:~/Projects/me/ajhc$ </div><div><br></div></div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 20 April 2013 10:55, Mikhail Glushenkov <span dir="ltr">&lt;<a href="mailto:the.dead.shall.rise@gmail.com" target="_blank">the.dead.shall.rise@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
This came up on StackOverflow [1]. When compiled with GHC (7.4.2 &amp;<br>
7.6.2), this simple program:<br>
<br>
main = print $ ack 4 1<br>
  where ack :: Int -&gt; Int -&gt; Int<br>
        ack 0 n = n+1<br>
        ack m 0 = ack (m-1) 1<br>
        ack m n = ack (m-1) (ack m (n-1))<br>
<br>
consumes all available memory on my machine and slows down to a crawl.<br>
However, when compiled with JHC it runs in constant space and is about<br>
as fast as the straightforward Ocaml version (see the SO question for<br>
benchmark numbers).<br>
<br>
I was able to fix the space leak by using CPS-conversion, but the<br>
CPS-converted version is still about 10 times slower than the naive<br>
version compiled with JHC.<br>
<br>
I looked both at the Core and Cmm, but couldn&#39;t find anything<br>
obviously wrong with the generated code - &#39;ack&#39; is compiled to a<br>
simple loop of type &#39;Int# -&gt; Int# -&gt; Int#&#39;. What&#39;s more frustrating is<br>
that running the program with +RTS -hc makes the space leak<br>
mysteriously vanish.<br>
<br>
Can someone please explain where the space leak comes from and if it&#39;s<br>
possible to further improve the runtime of this program with GHC?<br>
Apparently it&#39;s somehow connected to the stack management strategy,<br>
since running the program with a larger stack chunk size (+RTS -kc1M)<br>
makes the space leak go away. Interestingly, choosing smaller stack<br>
chunk sizes (256K, 512K) causes it to die with an OOM exception:<br>
<br>
$ time ./Test +RTS -kc256K<br>
Test: out of memory (requested 2097152 bytes)<br>
<br>
<br>
[1] <a href="http://stackoverflow.com/questions/16115815/ackermann-very-inefficient-with-haskell-ghc/16116074#16116074" target="_blank">http://stackoverflow.com/questions/16115815/ackermann-very-inefficient-with-haskell-ghc/16116074#16116074</a><br>


<span class="HOEnZb"><font color="#888888"><br>
--<br>
()  ascii ribbon campaign - against html e-mail<br>
/\  <a href="http://www.asciiribbon.org" target="_blank">www.asciiribbon.org</a>   - against proprietary attachments<br>
<br>
_______________________________________________<br>
Glasgow-haskell-users mailing list<br>
<a href="mailto:Glasgow-haskell-users@haskell.org">Glasgow-haskell-users@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/glasgow-haskell-users" target="_blank">http://www.haskell.org/mailman/listinfo/glasgow-haskell-users</a><br>
</font></span></blockquote></div><br></div>