- Glasgow-haskell-users

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

GHC and gcc 3.3.1
by Peter Simons 20 Oct '03

20 Oct '03

Just curious: Has anyone successfully compiled GHC with gcc 3.3.1 on Linux/x86? I'm having trouble here with both GHC 6.0 and GHC-current. Is that just me? Peter

1 0

RE: Haddock warnings for unresolved prelude functions
by Simon Marlow 20 Oct '03

20 Oct '03

> I'm using Haddock 0.5, compiled for GHC 6.0.1, and I get warnings when > "haddock"ing a simple module: > > Warning: module not found: Prelude > Warning: MyModule: the following names could not be resolved: > Prelude.[] Bool Eq > > I can see what's happening: I'm not passing Prelude.hs to > Haddock, but I'm > using pPrelude functions. But I don't want to pass it a Prelude.hs and > don't want the warnings either. Is there any way to force it to be > silent about unresolved Prelude functions? There isn't a way to make it silent, unfortunately (maybe I'll add one). These warnings are harmless - they just indicate that Haddock couldn't find the right place to link to for these Prelude types. If you want to generate the hyperlinks, then you need the .haddock file for the base package, which is distributed with GHC, and pass the --read-interface flag to Haddock (see the docs for details). Cheers, Simon

2 1

RE: DoCon as GHC test
by Simon Marlow 20 Oct '03

20 Oct '03

> I wonder: why do not you use the DoCon program as the test? No deep reasons, but DoCon is a *lot* of code to include in our nightly builds. Perhaps we should have a large lump of infrequently-run tests, including things like DoCon. Cheers, Simon

1 0

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

20 Oct '03

> using -fexcess-precision improves the runtime from about 180259 ns to > 140201 ns on my environment (Intel P3, 700Mhz, 384 MB Ram, Win2k). > That makes for me a speedup of 1.29. I tested the other flags, > -funbox-strict-fields -fliberate-case-threshold100 but did not see an > improvement. > Well, pure Haskell has a runtime of > > 140201 ns > > as stated above for a test of 9000 calls (thanks to the "sum $ map f > [inputlist]" pattern!). If i use the C aibd as foreign call, i get a > runtime of > > 80115 ns > > That's pretty good (both ghc6.0.1 on MinGW windows env). But > if i look at > my Java or C++ solution, then Java takes for the same task > (JVM 1.4.2_01 > client vm) > > 30000 ns. Looking at your code, it looks like you should add some more strictness. eg: sekantenVerfahren :: Funktion -> Genauigkeit -> Genauigkeit -> Int -> Double -> Double sekantenVerfahren f gx gy tiefe start = sekantenIter f tiefe gx gy x1 x2 y1 y2 where x1 = start x2 = start + start * 0.1 y1 = f x1 y2 = f x2 sekantenIter _ 0 _ _ _ x2 _ _ = x2 sekantenIter f tiefe gx gy x1 x2 y1 y2 = let x3 = x2 - y2 * (x2 - x1) / (y2 - y1) y3 = f x3 dy = y3 - y2 dx = x3 - x2 in if (istOk gx x3 dx) && (istOk gy y3 dy) then x3 else sekantenIter f (tiefe-1) gx gy x2 x3 y2 y3 Some of the parameters to the inner recursive function 'sekantenIter' are lazy. Try adding some seqs to help the strictness analyser: sekantenIter _ 0 _ _ _ x2 _ _ = x2 sekantenIter f tiefe gx gy x1 x2 y1 y2 = let x3 = x2 - y2 * (x2 - x1) / (y2 - y1) y3 = f x3 dy = y3 - y2 dx = x3 - x2 in x3 `seq` y3 `seq` dy `seq` dx `seq` if (istOk gx x3 dx) && (istOk gy y3 dy) then x3 else sekantenIter f (tiefe-1) gx gy x2 x3 y2 y3 Cheers, Simon

1 0

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

20 Oct '03

> 1. Use -fexcess-precision, unless you really need the > exact (lesser) precision. Otherwise each intermediate > result is spilled in memory. This hurts! There is currently a bug in GHC that the native code generator runs in -fexcess-precision mode all the time (in other words, it doesn't truncate to 64-bit precision like it should do). > 2. Use floats rather than doubles. You won't lose so > much precision because all intermediate computations > will use 80-bit precision. This saves some memory. > Plus, GHC doesn't align on 64 bits, which slows down > access to doubles. It is more-or-less random which intermediate computations will end up using 80-bit precision. You really shouldn't rely on this. The alignment issue is a problem, but we don't have an easy fix. If it weren't for that, the only reason to use Floats would be to save memory. If you get runtimes that vary randomly between two distinct values, the chances are that it's a Double alignment issue. Cheers, Simon

1 0