I would add a couple of points; these are implicit in a number of the responses but I would like to make them explicit. 1. Haskell is extremely sensitive to coding choices. You can hack up a C program and do a whole lot of things stupidly, and it will run at perhaps 1/2 the speed of a well written program. With Haskell I've found that a well written program often runs one or two orders of magnitude faster than a poorly written program. 2. As Simon PJ noted, performance bottlenecks often turn out to be in places that were unexpected. So, while it is of course prudent to examine the performance issues before starting to code, one must be careful about drawing conclusions. 3. There have certainly been many performance enhancements to ghc; these occur continuously. I agree with KP SCHUPKE that the comparison test is in many ways poorly executed; even if the results had more validity they would still be seriously out of date. Seth Kurtzberg

How can you take the results of a comparison like that seriously:

For example the "reverse file" test, here is the Haskell actually used:

main = interact $ unlines . reverse . lines

and here is the C:

/* -*- mode: c -*- * $Id: reversefile.gcc,v 1.10 2001/07/20 17:20:32 doug Exp $ * http://www.bagley.org/~doug/shootout/ * from Brad Knotwell */

#include #include #include #include

#define MAXREAD 4096

int main(int argc, char *argv[]) { int nread, len = 0, size = (4 * MAXREAD); char *cp, *buf = malloc(size + 1);

while((nread = read(0,(buf+len),MAXREAD)) > 0) { len += nread; if(MAXREAD > (size - len)) { size <<= 1; if((buf = realloc(buf,size+1)) == NULL) return(fprintf(stderr,"realloc failed\n"),EXIT_FAILURE); } }

if(nread == -1) return(fprintf(stderr,"read\n"),EXIT_FAILURE);

for (cp = buf+len-1; cp != buf; --cp,nread++) if ('\n' == *cp) { fwrite(cp+1,nread,1,stdout); nread = 0; }

fwrite(cp,nread+1,1,stdout); free(buf); return(EXIT_SUCCESS); }

Firstly, which of these is more likely to contain an error. A wrong program scores infinity on the time scale, so Haskell is infinitely faster than a wrong C program.

Secondly, The C program is using buffers, the Haskell program could use raw IO and buffers too. If it did it would ba a lot faster, and use about the same memory as the C code...

In my experiance poor Haskell performance is usually due to not understanding how the language works (for example head/tail are fast, init/last are slow), or not using the equivalent techniques in Haskell. To do the equivalent of the C you could use: http://www.haskell.org/~simonmar/io/System.IO.html

Regards, Keean. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

!DSPAM:405980ad100051440764324!