Similarly as the article points out, the compiler matters a lot: ICC can in certain cases be more than 200% faster than GCC with similar flags, and is generally 15-20% faster anyway, mainly due to more intelligent inlining and much faster (and more accurate with fpmath=fast) math libs.

Depends what level you mean - if you want to do all the optimisations yourself, C is better; but if you want to write code and let the compiler do the details, I would think higher-level is better (you can just write doWhatIMean() and the compiler will automatically choose the optimal implementation for your current problem and platform - where if you'd specified the implementation details yourself, you'd be sub-optimal in many cases)

Like, yes, no question, if you try and implement a tightloop in Haskell vs C, C is going to come out a lot faster.

However, no one writes Haskell like that! People rely pretty heavily on standard libraries (or even third party libraries), and on the optimizations afforded to them by the "rich" language of Haskell.

C might be capable of being faster, but that doesn't imply that a C program will inherently be faster than a similar Haskell program, especially if the programs are relatively large.

It is, of course, not the case that Haskell is faster than C with arbitrary effort expended tuning to the specific hardware - no one is claiming that.

* The vast majority of code doesn't need to be fast, and it's trivial to write code that's within a factor of 5 of optimized C. I can write Haskell at least 10x faster than I can write optimized C for the same problem.

* If you want code that's within a factor of 2 of C then you'll need to understand quite a bit about the internal details of the compiler, but your code won't get too ugly. I'd say it's about the same amount of work in both C and Haskell to get this level of performance.

* If you want code that's just as fast as optimized C then you'll need great understanding of both the compiler and the underlying hardware. At this point, you can expect your code will get hideously ugly. Also your code will break a lot when GHC versions change. I can write optimized C about 10x faster than I can write optimized Haskell.

Of course every problem is different, and this is only a rough average of my experience.

I suppose that's the point of this paper though, that "c-like performance" is a terribly vague term, meaningless without knowledge of the specific comparisons being made.

2) Despite #1 C is still closer to the machine than Haskell, and I'm not sure how you could maintain otherwise

3) Nearly all of the C optimizations will, at best, make a speedup by a constant factor. Things that add (or remove) an O(n) factor in Haskell can and do happen.

Perhaps my reading comprehension of the original post is different from Jacques' (or I'm just wrong), but I don't think that the original article made such a claim. Here's the TL;DR of the original article:

> TL;DR: Conventional wisdom is wrong. Nothing can beat highly micro-optimised C, but real everyday C code is not like that, and is often several times slower than the micro-optimised version would be. Meanwhile the high level of Haskell means that the compiler has lots of scope for doing micro-optimisation of its own. As a result it is quite common for everyday Haskell code to run faster than everyday C. Not always, of course, but enough to make the speed difference moot unless you actually plan on doing lots of micro-optimisation.

From this, I understood that in a larger program, most programmers wouldn't be doing the kind of micro-optimizations that they do for the Benchmarks Game. I figure that most code would be written following this pattern:

* Write code to follow the spec (usually without thinking too much about performance)

* Run the code, and evaluate its performance

* If the performance is good enough, you're done

* If the performance needs to be better, run a profiler

* Find the biggest bottleneck and optimize it

* Re-run the code and re-evaluate its performance

The original article took a micro-benchmark (a mistake in my opinion, because it's easy to micro-optimize every single detail of that code) and showed that in the case of Haskell, the first version was too slow, but that with the help of a profiler, finding the cause was easy, and the fix was trivial, while in C the profiler didn't show any problem with the code of the user, so it must be a problem in the standard library's code, and to fix it required changing the design of the program and making it more different than the spec. And I felt this was the author's real point; that to get the maximum performance from a C program, you'll need to code it not like a human would imagine it, but like a computer would, and it makes the code harder to maintain later on.

I think there are plenty of tricks involved in writing performant C code that aren't obvious. Things like cache behavior, memory access patterns, etc. The job of the compiler and PL is to help us by making it unnecessary to worry about such things unless we really need to.

It's a testament to the power of modern programming languages and computer speeds that there are many programmers who don't understand registers, caches, assembly, virtual memory, etc.

System wc, fastest of 5 runs:

      59180000  213180000 1407437834 wc_input
    11.53user 0.19system 0:11.74elapsed 99%CPU (0avgtext+0avgdata 2428maxresident)k
    0inputs+0outputs (0major+102minor)pagefaults 0swaps

     59180000 213180000 1407437834 wc_input
    6.08user 0.20system 0:06.29elapsed 99%CPU (0avgtext+0avgdata 2180maxresident)k
    0inputs+0outputs (0major+92minor)pagefaults 0swaps

If you write common C (and by common I mean what you see in well known daemons, kernels, etc) its generally at the very least on par. That's mostly because most of the functions come from libraries that have been optimized, in both cases.

"So here is the bottom line. If you really need your code to run as fast as possible, and you are planning to spend half your development time doing profiling and optimisation, then go ahead and write it in C because no other language (except possibly Assembler) will give you the level of control you need. But if you aren't planning to do a significant amount of micro-optimisation then you don't need C. Haskell will give you the same performance, or better, and cut your development and maintenance costs by 75 to 90 percent as well."

Note the 'same performance or better' in there.

Maybe you missed that bit in the original article?

This wasn't a large effort by any stretch of the imagination and a factor of 5 difference compared to the Haskell code isn't even in the same ballpark as "the same performance", and about a factor 10 difference with the C code listed in the original article. You'll notice no micro optimizations were done in the re-write, just some global re-arranging of the way data flows through the program.

The rest is in response to the misleading title, that Haskell is 'faster' than C, faster to program, faster to debug, easier to maintain and so on while making claims about performance that are not born out by real world comparisons.

Speed was the wrong thing to compare on here, and should not have been part of the original article without a serious effort to become equally proficient in both languages.

To quote the paper: "Clearly “properly”-written C++ can outperform Haskell. The challenge is in ?guring out what “proper” means."