When Haskell is Faster than C

When Haskell is Faster than C
paulspontifications.blogspot.com

He cherry picks optimizations for the Haskell, such as using Data.Vector.Unboxed instead of the regular lists and removing calls to isLetter, but then he rolls his own linked list and uses getc in the C version. He doesn't even have the correct return type for main.

Haskell written by decent Haskell programmers is faster than C written by poor C programmers. Not very surprising.

It is tempting to pull the code and fix it.

If you want to compare two languages make sure that you are proficient in both.

If I flatly said that JavaScript was 50x faster than C, I'd have butchered your story and some real points of interest here.

Supposing your team is productive in JavaScript, but not too exceptional with C, then a similar time investment can produce significantly faster JavaScript programs. In this way, in real practice, language productivity can totally drown technical performance differences. Even when you need to optimize, optimization is also subject to productivity differences.

It is probably inherently somewhat harder to reach the required level of ability in C to get the required performance, and thus to find people with this ability. Ergonomics and ease of entry don't just make people happy, they also have an impact on the performance of the average program to be written.

But even if it turns out that C is at no disadvantage here - it matters more what you will be able to use well. If C makes insane things possible that you will never do, they aren't a good reason for you to use C.

Moreover: following a general policy of writing JavaScript (or other favored language, within reason) is going to give you good-enough performance in a HUGE variety of problems.

Even if this performance is less than C's for an important program, there are two mitigating factors:

1. The slower performance may still be easily 'good enough'. There are diminishing returns on speed improvements. More speed does not always make the software better.

2. You can get the required speed by optimizing and replacing the bits which are bottlenecking the speed-critical bits, without committing to writing the entire project at 'max speed' out of the gate, which will often be a gigantic waste of resources on speed improvements that no one will ever see.

Most projects have limited applicability and limited lifespans. What matters isn't whether you are at maximum performance. What matters is whether performance is good enough for purpose.