- Glasgow-haskell-users

Control.Parallel.Strategies.parMap CPU usage
by Christian Hoener zu Siederdissen 30 Mar '09

30 Mar '09

Greetings, when using parMap (or parList and demanding) I see a curious pattern in CPU usage. Running "parMap rnf fib [1..100]" gives the following pattern of used CPUs: 4,3,2,1,4,3,2,1,... The fib function requires roughly two times the time if we go from fib(n) to fib(n+1), meaning that calculating the next element in the list always takes longer than the current. What I would like is a version of parMap that directly takes a free CPU and lets it calculate the next result, giving the usage pattern 4,4,4,4,... Below you find the simple Haskell program, which gives these results, please compile with "ghc --make -threaded -O2 Para.hs" and run on a machine with at least two cores and "./Para +RTS -N2" or better. I am not filing a bug yet as I would prefer to be told that I did it wrong and here is a better way: ... Thanks, Christian (Please assume that later on, "fib" will be replaced by something meaningful ;) # ghc --version # The Glorious Glasgow Haskell Compilation System, version 6.10.1 module Main where import Control.Parallel.Strategies -- parallel computation of fibonacci numbers in slow fib :: Int -> Int fib n | n < 1 = error "n < 1" | n == 1 = 1 | n == 2 = 1 | otherwise = fib (n-1) + fib(n-2) fibs = parMap rnf fib $ [1..100] -- fibs = let fs = map fib $ [1..100] in fs `demanding` (parList rnf fs) main = do mapM_ (putStrLn . show) $ zip [1..] fibs

4 5

copyFile and thread safety
by Neil Mitchell 30 Mar '09

30 Mar '09

Hi, Using GHC 6.8.3, the copyFile routine isn't thread safe - it crashes when two threads try and open the same file. I think that improvements were made to avoid security race conditions in GHC 6.10.1 (or the base library associated with it), and as a nice side effect they seem to have fixed the copyFile issues. However, it would be nice if someone could assure me that the copyFile issues were real but are now fixed. Replicating them is hard, but they randomly occur during a 1-hour build on my laptop, but not my desktop. I also note that copyFile starts with the process id and increments looking for a free filename. While that's fantastic if you are avoiding races with other processes (as I think the improvements were intended to address), it's not so great for avoiding races within the same process when different threads attempt to copy lots of files at once. In doing this, I suspect I've suffered lots of retries in the temporary name creation algorithm - should I be concerned about the performance aspect of this? Would an atomicModifyIORef and global temp file counter be a good idea? For now, I've got no immediate problems as I simply shell out to "cp" to do the copying - but it would be nice if the Haskell worked too. Thanks Neil

1 0

Few problems with building GHC
by Zachary Turner 30 Mar '09

30 Mar '09

Hi, This is my first time trying to compile GHC, so forgive me if these issues are mentioned somewhere. I couldn't find them anywhere on the wiki. First, I had originally installed a binary distribution and then tried to compile another program (a Haskell editor) that recommended I have source available for all libraries, since it would be able to give me better info in the editor. So this is why I decided to compile GHC from source in the first place. So I compiled GHC, and did make install, and I was _expecting_ that all of the library sources would end up in the directories alongside the binaries as well and that this is how the editor would be able to locate the source. But this did not happen, and instead my library folders look exactly like they do in the binary distribution that I installed by downloading the prepacked installer from the website. However, at one point I had downloaded some packages from Hackage and installed them with runhaskell configure, runhaskell build, runhaskell install on each of these new libraries, and the source did end up in the library directories alongside the binaries. So I feel like I'm doing something wrong in building GHC, and that when I install there should be a way to have the source of the libraries copied to the target directories. Can someone elaborate on how this is supposed to work for other programs that depend on the library sources to be able to find them? I know that of the 2 Hackage packages that I installed, the editor printed a message saying that it did find source for those two, but not for any other libraries. Second, I cannot create a windows build of GHC under cygwin. Looking at the Building Guide on the wiki suggests that this is indeed supported. However, when I try to build it I get cabal-bin.exe: Cannot find the program 'ghc' at '/cygdrive/c/dev/haskell/ghc/ghc-6.10.1/bin/ghc' or on the path make[1]: *** [bootstrapping.conf] Error 1 make[1]: Leaving directory `/cygdrive/c/dev/haskell/ghc/ghc-6.10.1-src/libraries' make: *** [stage1] Error 2 There seems to be some unix/windows confusion here, because it's looking for an executable file named "ghc", when the actual executable name is "ghc.exe". However, building under MSYS everything works perfectly. Is Cygwin just not supported, or do I need to change something here? I don't see any point in cluttering up my system with tons of extra software like MinGW, msys, etc if Cygwin works fine. Last, after building GHC when I go to run make install, I want the target location to be the original location of the compiler that I used to build GHC in the beginning. In other words, I want to have it overwrite the old version of GHC instead of going to the default install location under /usr/bin, etc... How can I specify the target install location?

2 3

Loop unrolling + fusion ?
by Don Stewart 27 Mar '09

27 Mar '09

Hey guys, We have nice fusion frameworks now. E.g. stream fusion on uvector, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/uvector Takes something like this: import Data.Array.Vector import Data.Bits main = print . productU . mapU (*2) . mapU (`shiftL` 2) $ replicateU (100000000 :: Int) (5::Int) and turns it into a loop like this: $wfold :: Int# -> Int# -> Int# $wfold = \ (ww_sWX :: Int#) (ww1_sX1 :: Int#) -> case ww1_sX1 of wild_B1 { __DEFAULT -> $wfold (*# ww_sWX 40) (+# wild_B1 1); 100000000 -> ww_sWX } Now, that's fine in my book. Going via -fasm, we get: Main_zdwfold_info: .LcYt: movq %rdi,%rax cmpq $100000000,%rax jne .LcYx movq %rsi,%rbx jmp *(%rbp) .LcYx: incq %rax imulq $40,%rsi movq %rax,%rdi jmp Main_zdwfold_info Ok: $ time ./product 0 ./product 0.31s user 0.00s system 96% cpu 0.316 total Going via C, however, we get: Main_zdwfold_info: cmpq $100000000, %rdi je .L6 .L2: leaq (%rsi,%rsi,4), %rax leaq 1(%rdi), %rdi leaq 0(,%rax,8), %rsi jmp Main_zdwfold_info Nice! $ time ./product 0 ./product 0.19s user 0.00s system 97% cpu 0.197 total So now, since we've gone to such effort to produce a tiny loop like, this, can't we unroll it just a little? Sadly, my attempts to get GCC to trigger its loop unroller on this guy haven't succeeded. -funroll-loops and -funroll-all-loops doesn't touch it, Anyone think of a way to apply Claus' TH unroller, or somehow convince GCC it is worth unrolling this guy, so we get the win of both aggressive high level fusion, and aggressive low level loop optimisations? -- Don

9 33

Int vs Word performance?
by Marco Túlio Gontijo e Silva 27 Mar '09

27 Mar '09

Hello, sorry for breaking the thread, I just got in the list. Simon Peyton-Jones simonpj at microsoft.com : > PS: in the case that no one gets around to creating such a patch, > creating a ticket that documents the problem and points to the needed > specialisations would be a start Was this created? I could not find something about it in the GHC trac. Greetings. -- marcot http://marcot.iaaeee.org/

2 1

Under OS X 10.5.6: GHC 6.10.1 Release Candidate 1
by Gregory Wright 27 Mar '09

27 Mar '09

I built ghc-6.10.1.20090314 on OS X 10.5.6 (Intel) using ghc 6.8.2 as a bootstrap compiler. The build was done using the MacPorts infrastructure. Summary test results: OVERALL SUMMARY for test run started at Tue Mar 17 15:31:38 EDT 2009 2334 total tests, which gave rise to 12487 test cases, of which 0 caused framework failures 2460 were skipped 9709 expected passes 258 expected failures 0 unexpected passes 60 unexpected failures Unexpected failures: 2469(ghci) apirecomp001(normal) bits (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) conc049(hpc) conc068(normal) derefnull(profc,profthreaded) divbyzero(profc,profthreaded) genUpTo (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) length001(optc,hpc,optasm,profc,profasm,threaded2,profthreaded) num009 (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) num012 (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) signals002(ghci) signals004(ghci,threaded1,threaded2,profthreaded) I haven't looked at the errors in detail, but generally the release candidate seems OK. BTW, a test target will be added to MacPorts's portfile for the 6.10.2 release, which will let you run the test suite by typing > sudo port test ghc and if you then install the tested build, a record of the test will be saved in $PREFIX/share/ghc-<version>/. Best Wishes, Greg

7 9

compilation of pattern-matching?
by Claus Reinke 27 Mar '09

27 Mar '09

I just noticed that GHC (6.11.20090320) seems to compile both f (a:b:c) = f (a:[]) = f [] = and f [] = f (a:[]) = f (a:b:c) = to something like (looking at Core, but writing source) f x = case x of { [] -> ..; (a:t) -> case t of { [] ->..; (b:c) ->..}} That doesn't seem right to me: if I try to give the patterns in the order from frequent to rare, in order to reduce jumps, I don't expect GHC to rearrange things. What is the rationale for this? And where can I read about GHC's pattern match compilation approach in general? Claus

9 34

Really bad code for single method dictionaries?
by Jason Dusek 27 Mar '09

27 Mar '09

I was reading the stream fusion code today and came across a comment stating that single element dictionaries interacted poorly with GHC's optimizer: class Unlifted a where [...] expose [...] -- | This makes GHC's optimiser happier; it sometimes produces really bad -- code for single-method dictionaries -- unlifted_dummy [...] A cursory search on GHC's Trac shows no corresponding bug; is this no longer a problem? A small problem? I would like to know more about it. -- Jason Dusek |...stream fusion code...| http://www.cse.unsw.edu.au/~dons/code/streams/list/Data/Stream.hs

6 5

Problem with a second installed version of the syb package
by José Pedro Magalhães 26 Mar '09

26 Mar '09

Hello all, I mentioned this problem before on IRC and remember this might have had something to do with syb having been unversioned in the release of GHC 6.10.1. However, I've tested this under 6.10.2-rc1 and the problem is still there. Concretely, the problem is: I've developed a sucessor package to syb-0.1.0.0. I can install it with runghc Setup.hs install. However, after having installed it I can't use it, getting this error when loading any module that imports Data.Generics: Bad interface file: C:\Program Files (x86)\Haskell\syb-0.2.0.0\ghc-6.10.1\Data\Generics.hi Something is amiss; requested module syb:Data.Generics differs from name found in the interface file syb-0.2.0.0:Data.Generics Failed, modules loaded: none. What is the problem here? Thanks, Pedro

2 5

Can't get editline support to work in 6.10.1
by Devon Tucker 26 Mar '09

26 Mar '09

Hello, I recently compiled and installed GHC 6.10.1 on Ubuntu 8.10 64-bit, after having installed 6.8 from the repositories. However when I launched ghci I discovered that the arrow keys and backspace did not work! After some quick googling I came to the conclusion that editline support was not enabled. I installed any package I could find named libedit*-dev and configured and compiled GHC again. Still no luck. Looking at my configure output I see a line like this (paraphrased, I don't have the output in front of me right now): Checking for ghc editline package... no. I really don't know what to do now. I have installed 6.10.1 on almost identical setups without any problem and I find ghci to be totally unproductive without command history and tab-completion. Any help would be greatly appreciated. Cheers, Devon Tucker

2 1