I just saw this on the OCaml list (in a posting by "Rafael 'Dido' Sevilla" <[EMAIL PROTECTED]> in the "Observations on OCaml vs. Haskell" thread). I can't believe that a simple "wc" implementation should be 570 times slower in Haskell than OCaml - could someone investigate and fix the test?
--KW 8-) http://caml.inria.fr/archives/200409/msg00485.html > > 2. Haskell strings are lists of characters > > > > It's annoying that strings aren't normally processed this way in OCaml, > > and even more annoying that (^) or (::) cannot be used in pattern > > matching over strings. I like Haskell's approach. The list > > concatenation operator is the same as the string concatenation operator > > in Haskell. > > > > This is something of an efficiency/elegance tradeoff. Making strings > act like lists means potentially boxing *every character in the string*. > In other words, it's potentially a very expensive way of doing business. > Paul Graham was mulling over this kind of tradeoff in his design of Arc, > as I recall. Another language that does this type of thing is Erlang, > and both languages seem to be significantly slower than OCaml in string > handling, at least as far as this site goes: > > http://shootout.alioth.debian.org/ > > For the word count benchmark OCaml scores 0.1850 seconds, while GHC is a > dismal last place at 105.2110 seconds! Even the bytecode ocaml is an > order of magnitude faster. The word frequency benchmark also shows this > kind of poor string handling performance for Haskell, with OCaml scoring > 0.5669 seconds, while GHC scores a truly dismal 6.4540, more than an > order of magnitude slower, and even the bytecode ocaml is faster at > 4.2644 seconds. > > All in all, it would appear that Haskell's approach has been expensive > in terms of performance, if the benchmarks are to be taken at face > value. Such are the tradeoffs language designers have to make. _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe