
Well, I believe that comparison is about solving a task, not writing code
in some particular way. I get your point, but I think that when comparing
language speed, you should use the best techniques each one has to offer,
it makes no sense otherwise.
If there was some kind of comparison made recently between Haskell and C++,
I'd be really glad to read a report. I like Haskell much more than C++, and
it'd be good to know, how write code in Haskell of speed equal or greater
to that of C++ (at least in some typical functional language tasks, like
math and data processing).
On Sun, May 6, 2012 at 12:23 PM, Roman Cheplyaka
* Artur
[2012-05-06 11:41:58+0300] isn't it that particular Haskell code is outperforming C (22 seconds vs. 33), just because the author uses recursion in C? I surely love Haskell, and the way it's code is easy parallelized, but that example seams not fair.
I think the point was to take two programs of similar code complexity (or, rather, simplicity) implementing the same algorithm (modulo parallelism).
So I'm not sure what exactly you're objecting to.
If you're saying that there are better algorithms to compute Fibonacci numbers, it's not relevant — the important thing that the two programs are computing the same thing in the same way.
If you're saying that in C an explicit stack should have been used instead of recursion, then it would increase the code complexity while having non-obvious performance benefits.
In any case, assuming that on this particular task Haskell is x times slower than C, taking sufficiently many cores and large enough N would outweigh that.
The again, I don't think that article was meant as a fair comparison between Haskell and C on an average task. (The chosen example consists of one loop which is easily parallelisable.) All it demonstrates is that it is very easy to exploit parallelism in Haskell when there's an opportunity.
-- Roman I. Cheplyaka :: http://ro-che.info/