- Glasgow-haskell-users

Re: -optc-O2 considered useful
by Bernd Brassel 20 May '08

20 May '08

I think it would be nice to have some speedy optimizations turned on by default in ghc. Might even be good to win new users. But I also think that much hacking for and around ghc+tool support needs a way to achieve what -O0 does today. So, how about an -O(-1) or flag?

1 0

whence _stub.c ?
by Conal Elliott 20 May '08

20 May '08

what causes ghc to emit a stub.c file? - Conal

3 2

Experiment: ghc-api and --split-objs
by Bertram Felgenhauer 20 May '08

20 May '08

Hi, I've made an experiment compiling ghc-api with --split-objs. To summarize, while this is not worthwhile for the compiler itself, it could be a huge win for plugin libraries. A fairly detailed description can be found here, http://int-e.home.tlink.de/haskell/README.ghc-api-test A tarball with the examples and auxiliary files is at http://int-e.home.tlink.de/haskell/ghc-api-test.tar.bz2 Open questions: - How much work would it to do this within the ghc build? - Maybe users that only need the parser can win as well? Haddock comes to mind here. In any case, this is food for thought, I hope. Enjoy, Bertram

2 1

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