- Glasgow-haskell-users

Haskell performance
by Sébastien Pierre 19 Mar '04

19 Mar '04

Hi all, I am a Haskell newbie, but have been interested in Haskell (and generally speaking ML-derivates) for some time. I am currently evaluating different languages for implementing an application which will have to manipulate large graphs representing the structure of programs and their evolution. In this respect, I need to find a language which offers a proper paradigm for implementation of graph algorithms (possibly involing some AI techniques), while offering great speed. Speed is in fact a crucial criterium for the language choice. I once read that Haskell was rather slow, especially when compared to Standard ML, which seems to be confirmed by "The Great Computer Language Shootout" (http://www.bagley.org/~doug/shootout/craps.shtml) However, this performance comparison seems rather outdated, so I wanted to know if GHC had improved in performance in the meantime. For now, the (somewhat unpleasing) conclusion I came with is that a Java (app core), Python (proto, UI) plus some interfaced C++ libs would be OK... but I would largely prefer to use a fonctional language for my application core. OCaml would have been just great, if only it had a properly designed library and a decent syntax... like Haskell ! What do you Haskell-experts could say about using Haskell for an application requiring graph processing performance ? TIA, -- Sébastien

8 10

RE: Cygwin binary?
by Simon Peyton-Jones 19 Mar '04

19 Mar '04

| But how do I produce binaries linked against cygwin? (Like to make darcs | work under windows)? And what if I want to take advantage of symlinks | etc. to make build process more convenient? We don't support targeting Cygwin, I'm afraid. Details here: http://www.haskell.org/ghc/docs/latest/html/building/winbuild.html Various people have worked to provide libraries offering Posix-like facilities for Haskell on Windows, to ease the kind of porting you are trying to do. I'm not sure what the status is, though. Mike Thomas might be a good person to ask. Simon | -----Original Message----- | From: Igor Bukanov [mailto:igor@fastmail.fm] | Sent: 16 March 2004 10:55 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users(a)haskell.org | Subject: Re: Cygwin binary? | | Simon Peyton-Jones wrote: | > GHC runs fine under Cygwin: http://haskell.org/ghc/download_ghc_62.html | > GHC itself does not require Cygwin, though, thank goodness. | | But how do I produce binaries linked against cygwin? (Like to make darcs | work under windows)? And what if I want to take advantage of symlinks | etc. to make build process more convenient? | | Regards, Igor

2 1

Data.HashTable bug
by Carsten Schultz 19 Mar '04

19 Mar '04

Hi, looking at `The Great Computer Language Shootout' mentioned in another thread, I wanted to try if Data.HashTable gives better results than Data.FiniteMap for the spell checker test http://www.bagley.org/~doug/shootout/bench/spellcheck/ I came up with the attached program. With data files http://www.bagley.org/data/shootout/spellcheck/Usr.Dict.Words http://www.bagley.org/data/shootout/spellcheck/Input it yields the result carsten@penne:~/t> ./a.out < Input blooper cager cashmere coming tablespoonful zuul However, the result should be only `zuul'. Is the problem in Data.HashTable? I have tested, 6.0, 6.2, 6.2.20040304. Greetings, Carsten -- Carsten Schultz (2:38, 33:47), FB Mathematik, FU Berlin http://carsten.codimi.de/ PGP/GPG key on the pgp.net key servers, fingerprint on my home page.

1 0

RE: Haskell performance
by Seth Kurtzberg 19 Mar '04

19 Mar '04

> | > I am currently evaluating different languages for implementing an > | > application which will have to manipulate large graphs representing > | > the structure of programs and their evolution. > | > | > Speed is in fact a crucial criterium for the language choice. > > A wise man once warned about the danger of premature optimisation. I > often spend ages labouring over efficiency aspects of my code (GHC, for > example) that turn out to be nowhere near the critical path. Language > choice is another example. > > My biased impression is that raw speed is seldom the determining factor in > language choice. Language shootouts are fun and motivating, and give > results that have the respectability that numbers confer. Other things > being equal, one would always choose the fastest vehicle; but other things > are *never* equal! On the contrary, other factors are much more > important than speed: how quick it is to get code written, how much > debugging is required once it is written, what libraries are available, > what the programming environment is like, how easy it is to modify the > program without giving rise to unforeseen bugs, etc etc. > > Sometimes performance is indeed central, but seldom. Usually the program > is either 10x faster than necessary or 10x slower than necessary. In > neither case does a 2x factor in language make much difference; in the > former case you're happy either way, in the latter you need to fix your > algorithm either way. > > For GHC in particular, there are many places where performance is less > good than it could be, simply due to lack of time from Simon and me to > tune the compiler. For example, there's been some correspondence recently > about array-processing loops that's still on my to-do list. We're always > looking for people to help improve GHC's performance, where the problem is > simply lack of effort. Speak up, guys! I would certainly be willing to assist in this area. > > That said, there are undoubtedly reasons why a high level language is > fundamentally never going to be as fast as a low level one. (GHC beats C > on nfib, but that's about all.) But I bet that this difference is only > crucial in a small minority of applications. > > Simon > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > !DSPAM:40597a4996431794457586! > > >

1 0

Re: Haskell performance
by MR K P SCHUPKE 19 Mar '04

19 Mar '04

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 <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #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.

3 2

RE: Haskell performance
by Simon Peyton-Jones 19 Mar '04

19 Mar '04

| > I am currently evaluating different languages for implementing an | > application which will have to manipulate large graphs representing | > the structure of programs and their evolution. | | > Speed is in fact a crucial criterium for the language choice. A wise man once warned about the danger of premature optimisation. I often spend ages labouring over efficiency aspects of my code (GHC, for example) that turn out to be nowhere near the critical path. Language choice is another example. My biased impression is that raw speed is seldom the determining factor in language choice. Language shootouts are fun and motivating, and give results that have the respectability that numbers confer. Other things being equal, one would always choose the fastest vehicle; but other things are *never* equal! On the contrary, other factors are much more important than speed: how quick it is to get code written, how much debugging is required once it is written, what libraries are available, what the programming environment is like, how easy it is to modify the program without giving rise to unforeseen bugs, etc etc. Sometimes performance is indeed central, but seldom. Usually the program is either 10x faster than necessary or 10x slower than necessary. In neither case does a 2x factor in language make much difference; in the former case you're happy either way, in the latter you need to fix your algorithm either way. For GHC in particular, there are many places where performance is less good than it could be, simply due to lack of time from Simon and me to tune the compiler. For example, there's been some correspondence recently about array-processing loops that's still on my to-do list. We're always looking for people to help improve GHC's performance, where the problem is simply lack of effort. Speak up, guys! That said, there are undoubtedly reasons why a high level language is fundamentally never going to be as fast as a low level one. (GHC beats C on nfib, but that's about all.) But I bet that this difference is only crucial in a small minority of applications. Simon

4 3

RE: Release Candidate for 6.2.1 available
by Simon Peyton-Jones 19 Mar '04

19 Mar '04

The particular problem that you are encountering seems to be some complicated interaction between Win98 and the GHC build system. We can't reproduce it, not having a Win98 box, and supporting building from source on Win98 isn't a major goal. It would have been great if the new RC fixed it, but I'd have been surprised. The RC was trying to test something more modest, namely that the 6.2.1rc binary release works correctly on Win98 systems, even when * the compiler itself is installed in a directory with spaces * temporary files are stored in a directory with spaces * the compiler is invoked in a directory with spaces Could you try that? Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Gour | Sent: 18 March 2004 08:56 | To: GHC users | Subject: Re: Release Candidate for 6.2.1 available | | Simon Marlow (simonmar(a)microsoft.com) wrote: | | > Please test. We'd especially like to hear from Win98/WinME users. Also | > try installing under a directory path with spaces in if you can. | | Here is the result of attempting to build ghc-6.2.1 with the 6.2.1rc binaries: | | [...] | | ==fptools== make boot - --unix -wr; | in /ghc/fptools/libraries/base | ------------------------------------------------------------------------ | ../../ghc/utils/hsc2hs/hsc2hs-inplace -Iinclude -I../../ghc/includes -Icbits/regex -I. | System/CPUTime.hsc | Executing: c:/MinGW/bin/gcc -c -mno-cygwin -D__GLASGOW_HASKELL__=602 - | Ic:/ghc/fptools/ghc/includes -Iinclude -I../../ghc/includes -Icbits/regex -I. | System\CPUTime_hsc_make.c -o System\CPUTime_hsc_make.o | Executing: c:/MinGW/bin/gcc System\CPUTime_hsc_make.o -o System\CPUTime_hsc_make.exe | | Fail: System\CPUTime_hsc_make.o: removeFile: does not exist (No such file or directory) | | make[2]: *** [System/CPUTime.hs] Error 1 | make[1]: *** [boot] Error 1 | make[1]: Leaving directory `/ghc/fptools/libraries' | make: *** [build] Error 1 | | | Again, the same problem: System\CPUTime_hsc_make.c -o System\CPUTime_hsc_make.o | | It should be: System/CPUTime_hsc_make.c -o System/CPUTime_hsc_make.o | | | I'm angry at myself not knowing Haskell and being able to fix this stuff :-( | | Sincerely, | Gour | | -- | Gour | gour(a)mail.inet.hr | Registered Linux User #278493 | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

RE: Haskell performance
by JP Bernardy 19 Mar '04

19 Mar '04

> Memory mapped files (mmap) should be even quicker. > But then you'll have > to use peek & co from Foreign to access the bytes. Just a thought: couldn't they be mapped to unboxed arrays? Cheers, JP. __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com

1 0

RE: Haskell performance
by Simon Marlow 19 Mar '04

19 Mar '04

> MR K P SCHUPKE <k.schupke(a)imperial.ac.uk> writes: > > > To do the equivalent of the C you could use: > > http://www.haskell.org/~simonmar/io/System.IO.html > > Is this documented anywhere? How do I use this? > The Haddoc documentation is a bit sparse. > This seems quite different from the System.IO module > installed with GHC 6.2, what's the relationship? The difference is that the System.IO that comes with GHC is actually implemented, rather than just documented :-) (to clarify, that link above is a half-baked design for a System.IO replacement. The discussion was taking place on libraries(a)haskell.org a while back, but has stalled). Cheers, Simon

3 2

RE: Haskell performance
by Simon Marlow 18 Mar '04

18 Mar '04

> For now, I assume that Haskell is very expressive, but has > the speed of most interpreted language, GHC is a *lot* faster than most interpreted languages :-P Usual caveats, and large handfuls of salt apply. Simon's cheat sheet for getting fast Haskell code: Rule 1: don't use String I/O. Rule 2: Profile your program. Find the inner loop. Look for overloading. Squash. Repeat. Look for laziness. Squash. Repeat. Cheers, Simon

1 0