7 ms·

> This article is in response to an earlier one comparing Haskell and C, which made the claim that Haskell beats out C when it comes to speed. Perhaps my readi

> This article is in response to an earlier one comparing Haskell and C, which made the claim that Haskell beats out C when it comes to speed. 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.

jacquesm 14y ago
> 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: The TL;DR is not representative of the whole article. It would be nice if it were but it isn't, so just reading the TL;DR is not enough, better do the short-enough;did-read version of that. Another commenter in this thread said more or less the same thing, I've responded to him here: http://news.ycombinator.com/item?id=5091270 http://news.ycombinator.com/item?id=5091270
- papsosouid 14y ago
  The whole article didn't make such a claim either. Your hate boner is clouding your judgement. Your article is far more biased and far less useful than the original. Especially all the random off-topic nonsense like "you should totally add error checking" and "lets change the style for no reason because I want to pad the length of this".
  - jacquesm 14y ago
    I can't parse your comment, please rephrase.
  - stcredzero 14y ago
    > Your hate boner is clouding your judgement. Should be a button or T-shirt.
pretoriusB 14y ago
>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. The TL;DR; is wrong too. It doesn't require micro-optimizations for a large real world C program to be faster than an equivalent Haskell program. All those abstractions and laziness in Haskell add up, and you get lower performance overall compared to ANY decent C implementation of a real world program, not just "highly optimized" ones.
- sixbrx 14y ago
  By the same token, the lack of higher level abstractions in C also add up in time and mental effort, and you're more likely to end up, in my experience, writing a dumber and more dangerous algorithm than you would in a language that has better safety features and more powerful abstractions.
  - zobzu 14y ago
    Even without trying to optimize. But I think the main issue is that "new" people don't realize most of their beloved languages aren't self hosted and are C compiled and/or that they're calling the C library for almost everything. Thus, knowing C matters a whole lot. Using it is another matter, and albeit the flexibility of C makes programs a lot more efficient every single time (when you have time and skill), it's understandable to use other languages. Still, some tasks should still be done in C instead of starting one of these countless runtime of the new language on the block. I'm slightly tired of the huge interpreted programs running extremely slower than they should these days. Even thus the hardware has gone way faster we still manage to reproduce 10y old programs that run slower than they did when we first made them.
zobzu 14y ago
IMO you can make C as fast or slow as you want it to be. If you write terrible C it's going to be slower than good Haskell. 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.

jacquesm 14y ago

> 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: The TL;DR is not representative of the whole article. It would be nice if it were but it isn't, so just reading the TL;DR is not enough, better do the short-enough;did-read version of that. Another commenter in this thread said more or less the same thing, I've responded to him here: http://news.ycombinator.com/item?id=5091270 http://news.ycombinator.com/item?id=5091270

papsosouid 14y ago
The whole article didn't make such a claim either. Your hate boner is clouding your judgement. Your article is far more biased and far less useful than the original. Especially all the random off-topic nonsense like "you should totally add error checking" and "lets change the style for no reason because I want to pad the length of this".
- jacquesm 14y ago
  I can't parse your comment, please rephrase.
- stcredzero 14y ago
  > Your hate boner is clouding your judgement. Should be a button or T-shirt.

pretoriusB 14y ago

>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. The TL;DR; is wrong too. It doesn't require micro-optimizations for a large real world C program to be faster than an equivalent Haskell program. All those abstractions and laziness in Haskell add up, and you get lower performance overall compared to ANY decent C implementation of a real world program, not just "highly optimized" ones.

sixbrx 14y ago
By the same token, the lack of higher level abstractions in C also add up in time and mental effort, and you're more likely to end up, in my experience, writing a dumber and more dangerous algorithm than you would in a language that has better safety features and more powerful abstractions.
- zobzu 14y ago
  Even without trying to optimize. But I think the main issue is that "new" people don't realize most of their beloved languages aren't self hosted and are C compiled and/or that they're calling the C library for almost everything. Thus, knowing C matters a whole lot. Using it is another matter, and albeit the flexibility of C makes programs a lot more efficient every single time (when you have time and skill), it's understandable to use other languages. Still, some tasks should still be done in C instead of starting one of these countless runtime of the new language on the block. I'm slightly tired of the huge interpreted programs running extremely slower than they should these days. Even thus the hardware has gone way faster we still manage to reproduce 10y old programs that run slower than they did when we first made them.

zobzu 14y ago

IMO you can make C as fast or slow as you want it to be. If you write terrible C it's going to be slower than good Haskell. 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.