October 2003 - Glasgow-haskell-users

Re: Faster, GHC, and floating point.
by Andreas.Schroeder＠gillardon.de 21 Oct '03

21 Oct '03

Yes, i got SSE to work with C++ with -march=pentium3 and -mfpmath=sse Well, don't make a difference for C++. It is still stuck at 140ms. But i must say that the speedup could be below the time resolution of my PC + Test. It is assumable that the improvement is similar to Haskell (about 4%) |---------+-----------------------------------------> | | Michael Weber | | | <michaelw(a)foldr.org> | | | Gesendet von: | | | glasgow-haskell-users-bounces@| | | haskell.org | | | | | | | | | 21.10.2003 11:47 | | | | |---------+-----------------------------------------> >-------------------------------------------------------------------------------------------------------------------| | | | An: Andreas.Schroeder(a)gillardon.de | | Kopie: glasgow-haskell-users(a)haskell.org | | Thema: Re: Faster, GHC, and floating point. | >-------------------------------------------------------------------------------------------------------------------| * Andreas.Schroeder(a)gillardon.de [2003-10-21T11:39+0200]: > Now, Haskell takes 4.57 the time of C++ (cygwin gnu C++ with -O2). Did you add the SSE options etc. to the C++ program as well when comparing Haskell vs. C++? What is the SSE speedup of C++ vs. C++/with SSE? Cheers, Michael _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: Faster, GHC, and floating point.
by Andreas.Schroeder＠gillardon.de 21 Oct '03

21 Oct '03

> > You put the blame on me for the bad performance of my code, > > I didn't mean to give that impression, sorry. Optimising Haskell code > is a delicate art which requires experience and sometimes a deep > knowledge of GHC's optimiser. This is a real problem, and we readily > accept that. I just wanted to say that i am aware that i am not (yet) a Haskell pro. I don't really feel blamed. I apologize for the formulation :-) Regards, Andreas Schroeder

1 0

RE: Faster, GHC, and floating point.
by Simon Marlow 21 Oct '03

21 Oct '03

> > really performance-critical code. Also this will tell you > whether your > > performance problems are due to strictness/boxing or > something else. It > > should be possible to obtain the same performance as C++ > (or better). > > Are you shure about this? And why are you shure? One can never be 100% sure, but your application is numerical and experience suggests that numerical code can often be optimised to yield code similar or better in performance than C. The pseudoknot benchmark (a while ago now) was a good example. > You put the blame on me for the bad performance of my code, I didn't mean to give that impression, sorry. Optimising Haskell code is a delicate art which requires experience and sometimes a deep knowledge of GHC's optimiser. This is a real problem, and we readily accept that. Cheers, Simon

1 0

RE: Faster, GHC, and floating point.
by Andreas.Schroeder＠gillardon.de 21 Oct '03

21 Oct '03

Hi Simon, > really performance-critical code. Also this will tell you whether your > performance problems are due to strictness/boxing or something else. It > should be possible to obtain the same performance as C++ (or better). Are you shure about this? And why are you shure? You put the blame on me for the bad performance of my code, and i can let this hold - i don't think that i am a haskell performance expert (though i am learning a lot through you people - thanks a lot). But i want to know if it is just _theoretically_ possible or really easily feasible. See, i know of some C++ hackers who will eventually have to change to Haskell. This will get hard for them, and i don't know if they can get into complex performance issues right from the start :-) But i guess the C++ / Haskell comparison will look far better for Haskell when changing to computations with large data structures. All i can tell by now is that Haskell works fine for me while C++ is ... hard to program. Regards, Andreas Schroeder

1 0

Re: Faster, GHC, and floating point.
by Andreas.Schroeder＠gillardon.de 21 Oct '03

21 Oct '03

Can't tell you, SSE is disabled by cygwin when i try -mfpmath=sse i get the message c++ AIBD.cpp Main.cpp -O2 -mfpmath=sse -o AIBD.exe cc1plus: warning: SSE instruction set disabled, using 387 arithmetics and the program it takes obviously the same time. Oh, and btw, using MinGW yields the same message for C/C++. For haskell actually, it _makes_ a difference. Don't ask me why and how. |---------+---------------------------> | | Michael Weber | | | <michaelw(a)foldr.| | | org> | | | | | | 21.10.2003 11:47| | | | |---------+---------------------------> >-------------------------------------------------------------------------------------------------------------------| | | | An: Andreas.Schroeder(a)gillardon.de | | Kopie: glasgow-haskell-users(a)haskell.org | | Thema: Re: Faster, GHC, and floating point. | >-------------------------------------------------------------------------------------------------------------------| * Andreas.Schroeder(a)gillardon.de [2003-10-21T11:39+0200]: > Now, Haskell takes 4.57 the time of C++ (cygwin gnu C++ with -O2). Did you add the SSE options etc. to the C++ program as well when comparing Haskell vs. C++? What is the SSE speedup of C++ vs. C++/with SSE? Cheers, Michael

1 0

RE: Faster, GHC, and floating point.
by Simon Marlow 21 Oct '03

21 Oct '03

> I added some `seq` 's to the code. > I also used SSE (not p4, i don't have the p4 available by > now, but i'll > test it) > and indeed, it runs _a bit_ faster: ~640 now vs. 711 ms > before (Speedup > 1.11). > > Now, Haskell takes 4.57 the time of C++ (cygwin gnu C++ with -O2). > > But if i look in the interface file by -ddump-hi, i see lot's > of U(L) 's > instead of S > or similar in the signature of the functions. I think that > U(L) is better > than L, but can i do better than U(L) somehow? Hard to tell without investigating the code in detail. U(L) is indeed better than S, though. If you're up to reading Core, you could try -ddump-simpl and see if the code generated by the compiler is what you expect. This is the only tool for investigating performance problems on a small scale. Or, you could try converting your code to use unboxed Double# values and primitive operations, instead of the plain Double. In general, it is better to convince the compiler to do this itself (by making things strict enough), but sometimes using Double# directly is a good idea for really performance-critical code. Also this will tell you whether your performance problems are due to strictness/boxing or something else. It should be possible to obtain the same performance as C++ (or better). Cheers, Simon

1 0

RE: Faster, GHC, and floating point.
by Andreas.Schroeder＠gillardon.de 21 Oct '03

21 Oct '03

Hi Simon, I added some `seq` 's to the code. I also used SSE (not p4, i don't have the p4 available by now, but i'll test it) and indeed, it runs _a bit_ faster: ~640 now vs. 711 ms before (Speedup 1.11). Now, Haskell takes 4.57 the time of C++ (cygwin gnu C++ with -O2). But if i look in the interface file by -ddump-hi, i see lot's of U(L) 's instead of S or similar in the signature of the functions. I think that U(L) is better than L, but can i do better than U(L) somehow? Regards, Andreas Schroeder |---------+---------------------------> | | "Simon Marlow" | | | <simonmar@micros| | | oft.com> | | | | | | 20.10.2003 18:18| | | | |---------+---------------------------> >-------------------------------------------------------------------------------------------------------------------| | | | An: <Andreas.Schroeder(a)gillardon.de>, <glasgow-haskell-users(a)haskell.org> | | Kopie: "JP Bernardy" <jyp_7(a)yahoo.com> | | Thema: RE: Faster, GHC, and floating point. | >-------------------------------------------------------------------------------------------------------------------| Looking at your code, it looks like you should add some more strictness.

2 1

RE: mips-sgi-irix bootstrapping
by Simon Marlow 21 Oct '03

21 Oct '03

> ----------- > 32 bit mips > ----------- > > * apply rmartine's latest CVS patch to MBlock.c > > * The build will go through once, but when you then have to > rebuild the > rts, pkg-conf will crash creating driver/package.conf.inplace. The > solution is to manually echo "[]" > > driver/package.conf.inplace, and to > touch driver/stamp-pkg-conf-rts > > * The build will dump core in the rts. Fire up gdb and you'll > see that it > died in gmp code around "__gmpn_tdiv_qr". > > The solution is to build an external libgmp, and override the target > architecture in the gmp build with ./configure --build=mips-sgi-irix. > This forces gmp to use 32 bit assembly, rather than going for 64 bit > code, which it does by default. > > * The build then crashes in __decodeDouble (), in GC.c, I > think it was. There is probably a 32/64 bit mismatch somewhere. You should be able to find out more by compiling up the RTS with debugging options and stepping through decodeDouble (this is ordinary C code). > ------ > 64 bit > ------ > > The libraries and compiler go though nicely, although you may see > warnings of the kind: > > ghc/Num.hc:5303: warning: this decimal constant is unsigned > only in ISO C90 Might be to do with some 64-bit constants in the generated .hc files, but I'm not sure. > * My current bug: following distrib/hc-build, after bootstrapping ghc/ > we rebuild the rts and libraries with the ghc binrary. AutoApply.hc is > generated. ghc then can't compile this file. If you look carefully at > the bottom of AutoApply.hc you'll see some strange characters: > > [ARG_8??] MK_SMALL_BITMAP(3,6), > [ARG_8?8] MK_SMALL_BITMAP(3,2), > [ARG_88?] MK_SMALL_BITMAP(3,4), > [ARG_888] MK_SMALL_BITMAP(3,0), > [ARG_8888] MK_SMALL_BITMAP(4,0), > [ARG_88888] MK_SMALL_BITMAP(5,0), > > This is a problem! The ARG_xxx characters should be either N or P or a > some other characters. Not strange ones as we see. Aha! It looks like toUpper isn't working properly. This is probably because GHC.Unicode has been compiled for a 32-bit machine. This is my fault :-( GHC.Unicode is processed by hsc2hs, which bakes in some platform-specific stuff into the .hs code before compiling it. The trouble is that hsc2hs is currently running on the host machine rather than the target machine, so GHC.Unicode is currently being compiled with 32-bit assumptions. This hasn't been a problem so far because we've eradicated hsc2hs code from the critical path, but I forgot about this when I introduced GHC.Unicode recently. oops! The solution for the time being is to take the C code generated by hsc2hs on the host machine using the --no-compile option, compile & run the program on the target machine using gcc, then take the .hs back to the host machine to generate the .hc file. Or you can wait till I've turned GHC.Unicode back into a plain .hs file. Cheers, Simon

2 1

Antwort: RE: Performance Tests in Haskell
by Andreas.Schroeder＠gillardon.de 21 Oct '03

21 Oct '03

thanks a lot! (and sorry if this question was trivial) regards, Andreas Schroeder |---------+---------------------------> | | "Simon Marlow" | | | <simonmar@micros| | | oft.com> | | | | | | 20.10.2003 17:23| | | | |---------+---------------------------> >-------------------------------------------------------------------------------------------------------------------| | | | An: <Andreas.Schroeder(a)gillardon.de>, <glasgow-haskell-users(a)haskell.org> | | Kopie: | | Thema: RE: Performance Tests in Haskell | >-------------------------------------------------------------------------------------------------------------------| > shure, "caibd" is the called C procedure from AIBD. > well then, i type > > > ghc Main.o AIBD.o HAIBDUtil.o -o HAIBD.exe > > then everything is fine, and i get my executable. > Now i wanted to profile, and added the options "-prof > --auto-all" to the > first ghc command. > When trying to link, i get lot's of undefined references: > > > ghc Main.o AIBD.o HAIBDUtil.o -o HAIBD.exe > > AIBD.o(.text+0x425):ghc1364.hc: undefined reference to `CC_LIST' > AIBD.o(.text+0x430):ghc1364.hc: undefined reference to `CC_LIST' > AIBD.o(.text+0x439):ghc1364.hc: undefined reference to `CC_ID' > AIBD.o(.text+0x444):ghc1364.hc: undefined reference to `CC_ID' > (...) > AIBD.o(.text+0x5fc):ghc1364.hc: undefined reference to `CCCS' > AIBD.o(.text+0x605):ghc1364.hc: undefined reference to `CCCS' > AIBD.o(.text+0x626):ghc1364.hc: undefined reference to > `PushCostCentre' > (...) You forgot to add -prof to the link line, too. Cheers, Simon

1 0

RE: GHC Lexer
by Simon Peyton-Jones 21 Oct '03

21 Oct '03

LexCore is the lexer for "ExternalCore". http://www.haskell.org/ghc/docs/papers/core.ps.gz For your purposes, you can ignore it. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Steffen Mazanek | Sent: 15 October 2003 13:45 | To: glasgow-haskell-users(a)haskell.org | Subject: GHC Lexer | | Hello, | | to add a new keyword, say "struct" to | the GHC, I have added ITstruct to data | type Token in module Lex.lhs. Further | on I have adapted ghcExtensionKeywordsFM. | Is this already sufficient for lexing? | In LexCore there is a function lexKeyword | without a comment. It is called by lexer | if the first character is %. What does this | mean? | | Thank you, | Steffen | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1