December 2006 - Glasgow-haskell-users

ghc-6.6-src-extralibs.tar.bz2
by Christian Maeder 09 Dec '06

09 Dec '06

The archive http://www.haskell.org/ghc/dist/6.6/ghc-6.6-src-extralibs.tar.bz2 does not contain the files ControlPoint.hs and Domain.hs from directory libraries/OpenGL/Graphics/Rendering/OpenGL/GL/ These files are listed by the binary distribution http://www.haskell.org/ghc/dist/6.6/ghc-6.6-i386-unknown-linux.tar.bz2 Personally I don't miss these files, but they are of course missing from distributions I (and possibly others) made. How imported are these files? They are also not listed in libraries/OpenGL/openGL.cabal. Cheers Christian

3 3

'accept' behavior with an asynchronous exception inside of a 'block'
by Cat Dancer 08 Dec '06

08 Dec '06

Chris Kuklewicz suggested I direct this question to the developers ^_^ If I use a network accept inside a block: block ( ... (clientSocket, sockAddr) <- accept serverSocket ... ) and the 'accept' unblocks a pending asynchronous exception and the exception gets thrown, does this mean that the 'accept' won't have accepted a network connection? Certainly this seems like desirable behavior, since if the 'accept' call might accept a network connection and *then* raise the asynchronous exception, the reference to the accepted connection would be lost. However I couldn't tell from the library documentation whether this was intended to be a guarantee of the 'accept' function or not.

1 1

Unlifted type variables in GHC
by Brian Alliet 08 Dec '06

08 Dec '06

What kind of problems could crop up if I try to create type variables with an unlifted kind inside GHC (not in user code, just inside the compiler)? I want to make ByteArray# and MutableByteArray# parameterized over their element types. ByteArray# would have kind # -> #, and MutableByteArray#, * -> # -> # . indexByteArray# would have the type (in pseudo haskell) forall (e::#). ByteArray# e -> Int# -> e. This would put all the ByteArray# operations (along with tagToEnum#) in that weird class of primops that have a polymorphic type but must be instantiated with a monomorphic type by the time it hits the code generator but that shouldn't be a big deal. Don't get too hung up on the ByteArray# example. I'm not actually proposing we change ByteArray# (I know it'll cause a few problems with the current UArray implementation). I'm just wondering if something like this is possible, and if so, what I should watch out for if I try to do it. Thanks, -Brian

2 2

bang patterns give fundamentally new capabilities?
by John Meacham 08 Dec '06

08 Dec '06

I was recently presented with the problem of writing a function like so seqInt__ :: forall a . a -> Int# -> Int# seqInt__ x y = x `seq` y which seems fine, except 'seq' of type forall a b . a -> b -> b cannot be applied to an unboxed value. I could not think of a way to actually get the behavior I wanted until I remembered bang patterns. seqInt__ :: forall a . a -> Int# -> Int# seqInt__ !x y = y which seems to work! my question is, is this actually something fundamentally new that bang patterns allow or was I just not able to figure out the "old" way to do it? Also, is there a way to do something similar but for 'lazy' rather than 'seq'? I want something of type type World__ = State# RealWorld {-# NOINLINE newWorld__ #-} newWorld__ :: a -> World__ newWorld__ x = realWord# -- ??? except that I need newWorld__ to be lazy in its first argument. I need to convince the opimizer that the World__ newWorld__ is returning depends on the argument passed to newWorld__. using any wacky ghc primitives in 6.6 is fine, I would just like something that stands up to ghc -O2. when compiling with -O, ghc is too clever and sees through tricks like this. (at least, that is what I think is happening) John -- John Meacham - ⑆repetae.net⑆john⑈

4 5

profiling experience
by Serge D. Mechveliani 08 Dec '06

08 Dec '06

People, I describe below my small experience with the time profiling in ghc-6.6. To make sure, consider first the following simple example: ------------------------------------------------------- import List (sort) main = {-# SCC "main" #-} let n = 5*10^4 :: Int in putStr (shows (f [1 .. n]) "\n") f :: [Int] -> Int f xs = {-# SCC "f" #-} case xs of [] -> 0 x: ys -> (g x) + (h x) + (f ys) where g x = {-# SCC "g" #-} last $ sort [0 .. (rem x 10)] h x = {-# SCC "h" #-} last $ sort [0 .. (rem x 20)] ------------------------------------------------------- Making: ghc -O -prof --make Main Running: ./Main +RTS -p -M100m -RTS This produces the report (its indentation shows which center is called from which): -------------------------------------------------------------------- total time = 3.00 secs (60 ticks @ 50 ms) total alloc = 130,608,300 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc h Main 65.0 67.3 g Main 33.3 30.9 main Main 1.7 1.5 individual inherited COST CENTRE MODULE no. entries %time %alloc %time %alloc MAIN MAIN 1 0 0.0 0.0 100.0 100.0 main Main 162 1 0.0 0.0 0.0 0.0 CAF Main 156 3 0.0 0.0 100.0 100.0 main Main 163 0 1.7 1.5 100.0 100.0 f Main 164 50001 0.0 0.3 98.3 98.5 h Main 166 50000 65.0 67.3 65.0 67.3 g Main 165 50000 33.3 30.9 33.3 30.9 CAF GHC.Handle 109 3 0.0 0.0 0.0 0.0 -------------------------------------------------------------------- To my mind, these numbers look all right: like I expected. Only I do not so firmly understand what is CAF, a "constant application form", a data which has cost, is assigned cost, but is out of the stack of calls. Is this profiling all right? Then, I need to find the main time eater in a certain concrete (and complex) example. Its profiling looks strange. I set SCC in all valuable inner loops in the modules Main.hs and LemmaSearch.hs. It shows --------------------------------------------- LemSearchList +RTS -p -M200m -RTS total time = 112.00 secs (2240 ticks @ 50 ms) total alloc = 3,813,365,740 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc CAF Main 95.5 96.1 splitDisjunctScheme LemmaSearch 2.5 2.2 addEquationsWithReduction LemmaSearch 1.3 1.4 --------------------------------------------- My idea was that some of the loops inside LemmaSearch must take almost all time. Instead, it shows that some CAF (anonymous, to me) in Main takes almost everything, and among places which I marked with SCC, the two are shown as 2.5% and 1.4%, and all the rest shown as zero: --------------------------------------------------- MAIN MAIN \ 1 0 0.0 0.0 100.0 100.0 CAF Main 2 80 57 96.0 96.1 99.9 99.9 ... --------------------------------------------------- The whole user project is build under -prof ("auto-all" skipped). The test Main.hs is built also under -prof. SCC are set only inside the functions Main.main and LemmaSearch.searchLemmataInInitial. What may consitute this strange CAF cost of 96% ? Kirsten Chevalier <catamorphism(a)gmail.com> wrote > I didn't look at your code all that carefully, but did you build the > GHC libraries with "-prof -auto-all"? (Not just "-prof".) If you don't > build the libraries with "-auto-all", then cost centres won't get > inserted for library functions, and if it's really a standard library > function that's taking all of that time, the profiling report won't > indicate that. I made ghc-6.6 from the official source in a standard way: ./configure ...; make; make install Does this presume that this also generates the .p.o GHC library versions for -prof -auto-all ? Generally, I do not guess, so far, what is happening. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 2

% of memory "unit" to heap-controlling RTS flags
by Ravi Nanavati 06 Dec '06

06 Dec '06

If you're trying to produce ghc executables that will work well without tweaking on machines with different configurations, it would handy to be able to control the heap requested based on the size of physical RAM. For instance, you might want to set -M to 100% or 80% of physical RAM and -H to (say) 25% of physical RAM. I was wondering what people would think if we had a new sort of "unit" for the various memory options that actually specified that the memory amount requested was as a percentage of physical RAM. So you could do something like: prog +RTS -M80% -H25% -RTS to start your heap at 25% of physical RAM and cap it at 80% of of physical RAM. You'd also be able to intermix % with the other memory units so you could do something like: prog +RTS -H256m -M95% -RTS to start your heap at 256m and cap it at 95% of physical RAM. How does that sound? - Ravi

3 2

large source for `bugs' e-list
by Serge D. Mechveliani 06 Dec '06

06 Dec '06

Dear GHC lists administrators, Is this appropriate to send to glasgow-haskell-bugs(a)haskell.org a large source archive of 800 Kb to build an example ? The code has several SCC marks, and maybe someone could look into why ghc-6.6 profiling reports such strange numbers, or explain why they are not strange. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

RE: Safepoint does not work as documented in paper
by Simon Marlow 05 Dec '06

05 Dec '06

Chris Kuklewicz wrote: > One odd problem: The paper on async exception defines: > > safePoint = unblock (return ()) > > but this simply does not work in my testing. Ever. Even using > {-# NOINLINE safePoint #-} or "-Onot" > > By comparision, this does work: safepoint = unblock (print "safe") > > So how can such a safePoint be written? The window in 'unblock (return ())' is tiny, I'm not really surprised if nothing ever gets through it. You might have more luck with 'unblock yield'. (BTW, I think glasgow-haskell-users(a)haskell.org is a more appropriate list, so I'm replying there instead). Cheers, Simon

3 2

Building GHC quickly
by dons＠cse.unsw.edu.au 05 Dec '06

05 Dec '06

Had a go today building GHC on a multcore linux box, with -j, just to see how fast it would go. Summary: you can build GHC from scratch in less than 10 minutes these days! More details here: http://cgi.cse.unsw.edu.au/~dons/blog/2006/12/03#build_ghc_fast -- Don

2 3

RE: [Haskell] Expecting more inlining for bit shifting
by roconnor＠theorem.ca 05 Dec '06

05 Dec '06

On Mon, 9 Oct 2006, Simon Peyton-Jones wrote: > Turns out that 'shift' is just too big to be inlined. (It's only called > once, but you have exported it too.) > > You can see GHC's inlining decisions by saying -ddump-inlinings. > > To make GHC keener to inline, use an INLINE pragma, or increase the > inlining size threshold e.g. -funfolding-threshold=12 Okay, when I force inlining for shift, (and I even need to do it for shiftR!) then the code is inlined in C. However this isn't the behaviour I want. Ideally the inlining should only happen when/because the second argument of shift is constant and the system knows that it can evaluate the case analysis away and that makes the function small. Am I being too naive on what to expect from my complier or is this reasonable? PS, is there a way to mark an imported instance of a class function (Data.Bits.shift for Data.Word.Word32) to be inlined? -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

6 18