May 2008 - Glasgow-haskell-users

making GHC from source
by Serge D. Mechveliani 19 May '08

19 May '08

People, I need to install ghc-6.8.2 from source. As I recall, this needs Happy and Alex. Right? Among Happy versions, it is visible only a couple latest ones, and to install any of them, one needs Cabal. Installing Cabal is as follows: make install mkdir -p dist/tmp ghc --make -cpp -Wall -DCABAL_VERSION=1,2,3,0 -i. -odir dist/tmp -hidir dist/tmp Setup.lhs -o setup make: ghc: command not found. We have a `make' loop: ghc --> Happy --> Cabal --> ghc Old Happy was good: it did not require GHC -- as I recall. Do I mistake? Now I have to install GHC from binary, and it will report of library version mismatch ... and so on. Do not you think that, generally, something is going wrong here? Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru http://www.botik.ru/~mechvel

2 1

bug in 6.8.2?
by Bulat Ziganshin 19 May '08

19 May '08

Hello glasgow-haskell-users, i've rather complicated class structure: class BufferData a where instance (FastBufferData a) => BufferData a where class FastBufferData a where instance (Storable a) => FastBufferData a where of course, it's compiled with -fallow-undecidable-instances -fallow-overlapping-instances -fallow-incoherent-instances BufferData class includes procedure `write`: class BufferData a where write :: OutStream -> a -> IO () there is writeAll procedure which uses this `write` and therefore should be able to write any BufferData instance: writeAll receiveBuf sendBuf cleanup x = bracket (create receiveBuf sendBuf cleanup) (closeOut) (\buf -> write buf x) it works great in 6.6.1 but in 6.8.2 GHC infers that writeAll can write only Storable instances, so i was forced to add signature to writeAll: writeAll :: (BufferData a) => RecvBuf -> SendBuf -> Cleanup -> a -> IO () the same problems raised many times when i switched from 6.6.1 to 6.8.2 - lots of procedures need to add signatures because by default 6.8.2 decided that they are restricted to Storable does GHC developers interested in minimal test case for this problem? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1

making Happy
by Serge D. Mechveliani 18 May '08

18 May '08

People, please, how can I download happy-1.14 source ? I need to install ghc-6.8.2 from source, and this needs Happy -- right? I would like to build Happy from source. Its page shows only 1.17. 1.14 was easy to build in a standard way: ./configue --path=... make make install And in 1.17, I am looking into its unzipped root directory, and do not see how to make and install. Generally, it is good to show an easy way to make and install somewhere in the root, in README ... Probably, Happy is a wise and remarkable project. But many people need only to `make' GHC, and do not intend to study right now many documents and philosophy about Happy and Cabal, etc. Thank you in advance for your help, ----------------- Serge Mechveliani mechvel(a)botik.ru

3 2

-optc-O2 considered useful
by Don Stewart 17 May '08

17 May '08

I discovered something today I didn't know. gcc -O2 can optimise out the computed jumps GHC produces in tight loops. Consider this program, import Data.Array.Vector import Data.Bits main = print . sumU . mapU (*2) . mapU (`shiftL` 2) $ replicateU (100000000 :: Int) (5::Int) Yields this core: $wfold :: Int# -> Int# -> Int# $wfold = \ (ww_sMp :: Int#) (ww1_sMt :: Int#) -> case ww1_sMt of wild_X10 { __DEFAULT -> $wfold (+# ww_sMp 40) (+# wild_X10 1); 100000000 -> ww_sMp And -O2 -fasm: Main_zdwfold_info: movq %rdi,%rax cmpq $100000000,%rax jne .LcOk movq %rsi,%rbx jmp *(%rbp) .LcOk: incq %rax addq $40,%rsi movq %rax,%rdi jmp Main_zdwfold_info $ time ./sum 4000000000 ./sum 0.19s user 0.00s system 101% cpu 0.188 total -O2 -fvia-C -optc-O: Main_zdwfold_info: cmpq $100000000, %rdi jne .L3 movq %rsi, %rbx movq (%rbp), %rax .L4: jmp *%rax .L3: addq $40, %rsi leaq 1(%rdi), %rdi movl $Main_zdwfold_info, %eax jmp .L4 $ time ./sum 4000000000 ./sum 0.34s user 0.00s system 94% cpu 0.361 total Hmm. That movl, jmp .L4 ; jmp *%rax looks sucky, and performance got worse. And now with -O2 -fvia-C -optc-O2 Main_zdwfold_info: cmpq $100000000, %rdi je .L5 .L3: addq $40, %rsi leaq 1(%rdi), %rdi jmp Main_zdwfold_info $ time ./sum 4000000000 ./sum 0.11s user 0.02s system 106% cpu 0.122 total Woot, back in business. -- Don

6 6

Building GHC
by Dominic Steinitz 16 May '08

16 May '08

When I look at the instructions http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources they say the distribution is split in two but when I look at http://darcs.haskell.org/ it seems to be split in three ghc-HEAD-2007-12-16-..> 16-Dec-2007 14:25 102M ghc-HEAD-2007-12-16-..> 16-Dec-2007 14:20 92M ghc-HEAD-2007-12-16-..> 16-Dec-2007 14:12 57M I'm assuming I unpack these on top of each other but I'd be grateful if someone could confirm this. Thanks, Dominic.

2 1

How do I check the optimisation level of the built-in splitAt? Is something other than -O2 giving me my speed increase?
by Richard Kelsall 15 May '08

15 May '08

Hello Glasgow-Haskell Users, It was suggested to me in this thread in Haskell-Cafe http://www.haskell.org/pipermail/haskell-cafe/2008-May/042797.html which was a subsidiary of a previous thread http://www.haskell.org/pipermail/haskell-cafe/2008-April/042155.html that there might be some reason other than the -O2 optimisation level I applied to my version of splitAt that was making my program run about 30% faster than when I used the built-in splitAt. Can somebody tell me how to check what the -O level is for the built-in splitAt? Or alternatively tell me what the optimisation level is for the libraries. (Sorry I'm not sure of the right terminology for these built-in / library / Prelude things.) Richard.

4 4

laziness, memoization and inlining
by Scott Dillard 15 May '08

15 May '08

Hi Everybody, I'm experiencing some undesirable performance behavior, I suspect from inlining things that shouldn't be, defeating my memoization attempts. I've been experimenting with purely functional 3D modeling code, so a mesh is (initially) something like > type Mesh = Map (Int,Int) (Int,Int) that is, a function from from an edge to the next edge around the face, where an edge is a pair of Ints (the vertices.) This nice and pure and everything, but its slow to read from. So I have another immutable pointer-based representation > data Edge = Edge { edgeOrg :: Int , edgeSym :: Edge , edgeNext :: Edge } which is something like a half-edge, for those familiar with such things. Its basically a big net made of circular lists that are tied together. I do the knot tying stuff to create this thing, > memoMesh :: Map (Int,Int) (Int,Int) -> Edge Int > memoMesh nexts = head $ Map.elems ties > where > ties = Map.mapWithKey (\ij _ -> make ij) nexts > lookup ij = trace "hello" $ fromJust $ Map.lookup ij ties > make ij@(i,j) = Edge i (lookup (j,i)) (lookup . fromJust $ Map.lookup ij nexts) The program first loads the model file and creates the Edge-based mesh using the memoMesh function. The result is then captured in the closure for the rendering callback in GLUT. When I compile with -O0 I see the "hello" traces only during the first drawing. Subsequent redraws are fast and output no traces. When I compile with -O1 or -O2, the traces get output on every redraw, and its very slow. I suspect all of the calls which create the mesh are inlined into the rendering callback, effectively rebuilding the mesh on every draw. I've tried littering NOINLINE pragmas all around, to no avail. The main function is something like > main = do > initGlut ... > rawMesh <- loadMeshFile ... > let > mesh = memoMesh rawMesh > otherstuff = ... > display = > draw mesh >> amongOtherThings > displayCallback $= display > glutMainLoop Can someone help me understand what's going on here? Is there a nice solution to this, hopefully a single strategic pragma or something? Scott

5 5

How MD are .hi files?
by Matthias Kilian 15 May '08

15 May '08

Hi, for an unregisterised ghc-6.8.2 (or newer), are the .hi files dependent (except for the 32 vs. 64 bit word size)? I had a quick look at the stuff in compiler/iface, but the only MD part I found was that 32/64 bit difference. TIA Ciao, Kili ps: if you think this sounds like a complete newbie question, you're right; I've been far too busy hacking on boring stuff like Makefiles, and didn't have time to look at the interesting code (i.e. ghc itself). My knowledge of ghc's internals is at the state of 1998, or even older, I really don't remember ;-) -- Options are good. As long as they are optional. -- Artur Grabowski

2 3

Performance: Faster to define a function writing out all arguments?
by Alexander Fuchs 14 May '08

14 May '08

Hi there, I am trying to write my first serious Haskell program, but have problems understanding 'strange' performance results. It seems to be a ghc specific question, so I am asking here. In a happy parser I have this code 1): %monad { Parsed } { thenP } { returnP } type Parsed = State Env.Env returnP :: a -> Parsed a returnP a = return a thenP :: Parsed a -> (a -> Parsed b) -> Parsed b thenP x k = x >>= k An alternative was this 2) (yes, redundant in happy): returnP :: a -> Parsed a returnP = return thenP :: Parsed a -> (a -> Parsed b) -> Parsed b thenP = (>>=) And strangely enough on my machine 1) is faster by a few percent than 2) using ghc 6.8.2 with -O2. A few percent might seem unimportant, but I am currently developing my Haskell style. And I want to write efficient code by default, if that doesn't lead to obfuscation. Now, first I dislike using option 1) because it seems pointlessly verbose. Second, I have no clue why option 2) should be faster. Using ghc -O2 -C I get two code blocks with 1) (appended at the end of this mail), whereas I get nothing with 2. Unfortunately, that doesn't help me as I have no clue what it means. There are also various strictness annotations throughout the code to make parsing less memory hungry (and getting an intuition about what is appropriate here drives me crazy). Random guess: perhaps somehow strictness analysis of ghc benefits from the code in 1)? Or does ghc create specialized versions of return and >>= for State instantiated to Parsed, i.e. State Env.Env? Anyhow, I am puzzled and grateful for any explanations and recommendations about what is going on and when to avoid style 2). Thanks, Alexander C-- code blocks: ------------------------------------------------------- EI_(DarwinziTptpziParser_a106_info); StgWord DarwinziTptpziParser_a106_closure[] = { (W_)&DarwinziTptpziParser_a106_info }; static StgWord s8Ey_info[] = { 0x42U, 0x22U }; IF_(s8Ey_ret) { W_ _c8EL; FB_ Sp[2] = *((P_)(R1.w+7)); _c8EL = *((P_)(R1.w+3)); R1.w = Sp[1]; Sp[1] = _c8EL; Sp=Sp+1; JMP_((W_)&stg_ap_pp_fast); FE_ } StgWord DarwinziTptpziParser_a106_info[] = { 0x30014U, 0x0, 0xfU }; EI_(DarwinziTptpziParser_a106_closure); II_(s8Ey_info); FN_(DarwinziTptpziParser_a106_entry) { FB_ if ((W_)(((W_)Sp - 0x4U) < (W_)SpLim)) goto _c8EO; R1.w = *Sp; Sp[-1] = Sp[2]; *Sp = (W_)&s8Ey_info; Sp=Sp-1; JMP_((W_)&stg_ap_p_fast); _c8EO: R1.w = (W_)&DarwinziTptpziParser_a106_closure; JMP_(stg_gc_fun); FE_ } ------------------------------------------------------- ------------------------------------------------------- II_(r6AT_info); static StgWord r6AT_closure[] = { (W_)&r6AT_info, 0x0, 0x0, 0x0 }; static char c97W_str[] = "Internal Happy error\012"; static StgWord r6AT_info[] = { 0x0, 0x16U }; EI_(base_GHCziBase_unpackCStringzh_info); IF_(r6AT_entry) { FB_ if ((W_)(((W_)Sp - 0xcU) < (W_)SpLim)) goto _c97Z; Hp=Hp+2; if ((W_)((W_)Hp > (W_)HpLim)) goto _c97Z; Hp[-1] = (W_)&stg_CAF_BLACKHOLE_info; newCAF((void *)R1.w); R1.p[1] = (W_)Hp-4; *R1.p = (W_)&stg_IND_STATIC_info; Sp[-2] = (W_)&stg_upd_frame_info; Sp[-1] = (W_)Hp-4; Sp[-3] = (W_)&c97W_str; Sp=Sp-3; JMP_((W_)&base_GHCziBase_unpackCStringzh_info); _c97Z: HpAlloc = 0x8U; JMP_(stg_gc_enter_1); FE_ } EI_(base_GHCziErr_error_closure); II_(r6AT_closure); StgWord DarwinziTptpziParser_notHappyAtAll_srt[] = { (W_)&base_GHCziErr_error_closure, (W_)&r6AT_closure }; EI_(DarwinziTptpziParser_notHappyAtAll_info); StgWord DarwinziTptpziParser_notHappyAtAll_closure[] = { (W_)&DarwinziTptpziParser_notHappyAtAll_info, 0x0, 0x0, 0x0 }; StgWord DarwinziTptpziParser_notHappyAtAll_info[] = { ((W_)&DarwinziTptpziParser_notHappyAtAll_srt+0), 0x0, 0x30016U }; EI_(base_GHCziErr_error_closure); II_(r6AT_closure); FN_(DarwinziTptpziParser_notHappyAtAll_entry) { FB_ if ((W_)(((W_)Sp - 0xcU) < (W_)SpLim)) goto _c989; Hp=Hp+2; if ((W_)((W_)Hp > (W_)HpLim)) goto _c989; Hp[-1] = (W_)&stg_CAF_BLACKHOLE_info; newCAF((void *)R1.w); R1.p[1] = (W_)Hp-4; *R1.p = (W_)&stg_IND_STATIC_info; Sp[-2] = (W_)&stg_upd_frame_info; Sp[-1] = (W_)Hp-4; R1.w = (W_)&base_GHCziErr_error_closure; Sp[-3] = (W_)&r6AT_closure; Sp=Sp-3; JMP_((W_)&stg_ap_p_fast); _c989: HpAlloc = 0x8U; JMP_(stg_gc_enter_1); FE_ } -------------------------------------------------------

4 6

small and compact ghc distribution
by leledumbo 14 May '08

14 May '08

Currently, GHC distribution is VERY BIG (about 410 MB). 2 Things that I noticed which contributed most of this problem are: libraries (about 220 MB) and GCC and friends compiler (including perl, ar, as, ld, etc). I'm a college student and I just want to learn functional programming with Haskell. No need to access libraries other than GHC rtl (or whatever you call it). I already have gcc on my machine, does GHC still need its own? Will there be any small and compact GHC distribution (if someone wants to make it, I'd be very grateful)? -- View this message in context: http://www.nabble.com/small-and-compact-ghc-distribution-tp17223701p1722370… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

2 2