Sorry sorry sorry ^^<br>I read too fast and realized I was wrong before you sent this.<br><br>Okay so then it would be nice that somewhere with higher skills tells us where does Haskell recursive calls stand when compared to C's.<br>
<br><div class="gmail_quote">2012/5/6 Roman Cheplyaka <span dir="ltr"><<a href="mailto:roma@ro-che.info" target="_blank">roma@ro-che.info</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It is not tail-recursive.<br>
<br>
* Yves Parès <<a href="mailto:yves.pares@gmail.com">yves.pares@gmail.com</a>> [2012-05-06 10:58:45+0200]<br>
<div class="im">> I do not agree: the fib function is tail-recursive, any good C compiler is<br>
> able to optimize away the calls and reduce it to a mere loop.<br>
> At least that's what I learnt about tail recursion in C with GCC.<br>
><br>
> 2012/5/6 Artur <<a href="mailto:apeka1990@gmail.com">apeka1990@gmail.com</a>><br>
><br>
> > On <a href="tel:06.05.2012%2010" value="+33605201210">06.05.2012 10</a>:44, Ivan Lazar Miljenovic wrote:<br>
> ><br>
> >> On 6 May 2012 16:40, Janek S.<<a href="mailto:fremenzone@poczta.onet.pl">fremenzone@poczta.onet.pl</a>> wrote:<br>
> >><br>
> >>> Hi,<br>
> >>><br>
> >>> a couple of times I've encountered a statement that Haskell programs can<br>
> >>> have performance<br>
> >>> comparable to programs in C/C++. I've even read that thanks to<br>
> >>> functional nature of Haskell,<br>
> >>> compiler can reason and make guarantess about the code and use that<br>
> >>> knowledge to automatically<br>
> >>> parallelize the program without any explicit parallelizing commands in<br>
> >>> the code. I haven't seen<br>
> >>> any sort of evidence that would support such claims. Can anyone provide<br>
> >>> a code in Haskell that<br>
> >>> performs better in terms of execution speed than a well-written C/C++<br>
> >>> program? Both Haskell and C<br>
> >>> programs should implement the same algorithm (merge sort in Haskell<br>
> >>> outperforming bubble sort in<br>
> >>> C doesn't count), though I guess that using Haskell-specific idioms and<br>
> >>> optimizations is of<br>
> >>> course allowed.<br>
> >>><br>
</div>> >> How about <a href="http://donsbot.wordpress.com/**2007/11/29/use-those-extra-**" target="_blank">http://donsbot.wordpress.com/**2007/11/29/use-those-extra-**</a><br>
> >> cores-and-beat-c-today-**parallel-haskell-redux/<<a href="http://donsbot.wordpress.com/2007/11/29/use-those-extra-cores-and-beat-c-today-parallel-haskell-redux/" target="_blank">http://donsbot.wordpress.com/2007/11/29/use-those-extra-cores-and-beat-c-today-parallel-haskell-redux/</a>><br>
<div class="im">> >> ?<br>
> >><br>
> >> Hi,<br>
> ><br>
> > isn't it that particular Haskell code is outperforming C (22 seconds vs.<br>
> > 33), just because the author uses recursion in C? I surely love Haskell,<br>
> > and the way it's code is easy parallelized, but that example seams not fair.<br>
> ><br>
> ><br>
</div>> > ______________________________**_________________<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><<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a>><br>
<div class="HOEnZb"><div class="h5">> ><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>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Roman I. Cheplyaka :: <a href="http://ro-che.info/" target="_blank">http://ro-che.info/</a><br>
</font></span></blockquote></div><br>