[Haskell-cafe] Can Haskell outperform C++?

[wren ng thornton]

On 5/6/12 2:40 AM, Janek S. wrote:
> Hi,
>
> a couple of times I've encountered a statement that Haskell programs can have performance
> comparable to programs in C/C++. I've even read that thanks to functional nature of Haskell,
> compiler can reason and make guarantess about the code and use that knowledge to automatically
> parallelize the program without any explicit parallelizing commands in the code. I haven't seen
> any sort of evidence that would support such claims. Can anyone provide a code in Haskell that
> performs better in terms of execution speed than a well-written C/C++ program? Both Haskell and C
> programs should implement the same algorithm (merge sort in Haskell outperforming bubble sort in
> C doesn't count), though I guess that using Haskell-specific idioms and optimizations is of
> course allowed.

For a quantitative comparison in a very narrow domain, check out:

     Duncan Coutts, Don Stewart, Roman Leshchinskiy (2007).
     Rewriting Haskell Strings.
     http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.90.3166

Fundamentally, neither language can be faster than the other since it's 
possible to hack around in assembly code with both of them. Therefore, 
asking which is faster when implementing identical algorithms is not a 
meaningful question. In reality, most people don't spend time 
microoptimizing assembly code these days; instead, people implement 
whatever seems good enough given the constraints on development time and 
execution time. Thus, the real question should be: which algorithms are 
made easy to implement by the language?--- either in terms of raw syntax 
(hence maintainability), or in terms of man-hours worked (hence 
development time).

The ease of parallelism in Haskell is a prime example of the fact that, 
while all of it is technically possible to re-implement in C with 
identical performance, Haskell is simply better because the parallel 
code is already implemented and programs using it are statically checked 
for type safety, which reduces the development time significantly. But 
for the most part, that isn't a comparison of languages, it's a 
comparison of libraries (for which the language of Haskell facilitates 
making good libraries).

Once you approach the real question and try to quantify it, you're going 
to run into the issues that arise any time you try to quantify human 
populations. What works well for one project or company is not 
necessarily going to generalize to a different set of developers; thus, 
in order to ensure ecological validity in your comparison, you'll need 
to compare lots of different kinds of groups. But of course, your 
ability to do so is biased by the social environment; e.g., imperative 
languages are more mainstream and therefore afford different developer 
communities than functional languages do. Thus, not only can you not 
come up with a simple metric that does justice to the question, but the 
answer to the question is going to evolve and change over time ---even 
if the underlying languages and compilers do not change--- because 
society changes and evolves over time.

For as often as this question is asked, and for as much as it could be 
interesting to actually get an answer, this isn't the sort of research 
that computer scientists are (generally) trained to do. Which is why it 
isn't generally done.

-- 
Live well,
~wren