[Haskell-cafe] Re: Haskell Speed

[S Koray Can]

Daniel Carrera wrote:
> It looks like Haskell doesn't do very well. It seems to be near the 
> bottom of the pile in most tests. Is this due to the inherent design of 
> Haskell or is it merely the fact that GHC is young and hasn't had as 
> much time to optimize as other compilers?

I don't think it's that bad. It depends on the particular test, but it's 
  almost comparable to Java, iirc. On some tests, it's terrible, though.

> For example, another very slow language is Ruby. In Ruby's case, there 
> is a design factor that will always make it slow. I wonder if Haskell is 
> in a smilar situation.

Haskell's syntax and type system are powerful enough that technically 
there are a lot of optimizations possible without involving FFI. It may 
become ugly, though, and less and less safe e.g. if you have to use 
unsafeWrite's to update arrays to eliminate boundchecks, etc.

A lot of the benchmark problems (at least the ones GHC seems to do worse 
than usual, e.g. 
http://shootout.alioth.debian.org/gp4/benchmark.php?test=revcomp&lang=all) 
involve some sort of string processing. Idiomatic Haskell dictates that 
one uses a linked list of Char's because FastString is not  part of the 
language. That is a lot of overhead for values as small as one byte. 
Also, the input string is 25M characters long in the revcomp case, thus 
there's a lot of difference between reversing it with and without 
in-place updates. If you look at the OCaml implementations, they usually 
use references, in-place updates and compile with boundchecks disabled 
(but that is idiomatic ocaml code).

However, I don't think it is right to downplay these benchmarks. Such 
little tasks exist in one form or another in bigger programs. Perhaps we 
should include mutable arrays in 'idiomatic' Haskell as well. Otherwise 
it is similar to proposing std::getline() take a std::List<Char> as an 
argument from a performance point of view.

And it's not right to blame naive implementors, either. I couldn't have 
guessed that the see the difference between the two haskell 
implementations for sum-file would be so massive. It's a pity that the 
super-slow version could very well be the version your coworker would 
have written even if you wouldn't.

Cheers,
Koray