[Haskell-cafe] Can Haskell outperform C++?
wren ng thornton
wren at freegeek.org
Mon May 7 01:32:25 CEST 2012
On 5/6/12 2:40 AM, Janek S. wrote:
> 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.
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
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.
More information about the Haskell-Cafe