March 2004 - Glasgow-haskell-users

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

18 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 18 Mar '04

18 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 18 Mar '04

18 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 18 Mar '04

18 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 18 Mar '04

18 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 18 Mar '04

18 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 18 Mar '04

18 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 18 Mar '04

18 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

RE: finding C compiler and preprocessor?
by Simon Peyton-Jones 18 Mar '04

18 Mar '04

ghc -v Foo.hs will show you what C compiler GHC invokes S | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of David Roundy | Sent: 18 March 2004 14:05 | To: glasgow-haskell-users(a)haskell.org | Subject: finding C compiler and preprocessor? | | Hello, | | Is there any way to find out what C compiler and preprocessor are used by | ghc? | | I've run into problems with a windows user, since the ghc distribution | apparently uses a different compiler than the one that my configure script | finds, and so the configure script indicates that a certain header file is | found, but then the program fails to compile, since ghc doesn't find them. | :( The only other option that comes to mind would be to write autoconf | macros to check for header files and/or libraries using ghc, but that | sounds to me like a real pain. | | Alternatively, if I could tell ghc which compiler to use, that would work | as well, since autoconf is perfectly capable of identifying a working C | compiler. | | I've tried telling autoconf that ghc is my C compiler, but that fails when | the user provides a CFLAGS that isn't supported by ghc. One could get | around this by prepending -optc to all the CFLAGS (but I haven't figured | out how to do this in shell), but then there is still the trouble of trying | to convince ghc to preprocess a C file with the C preprocessor. :( | | Any suggestions would be welcome! | -- | David Roundy | http://www.abridgegame.org | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0