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