March 2011 - Glasgow-haskell-users

Configuring specific packges in libraries/ during ghc build
by Tyler Pirtle 07 Mar '11

07 Mar '11

My toolchain is a little silly. ;) It doesn't have ncurses in the obvious place, so by the time my build gets around to doing libraries/terminfo, the terminfo configure bails because it can't find the curses headers. I can work around this, by building the library manually, but is there an easy way for me to get a hold of specific cabal options when calling specific packages during build? "inplace/bin/ghc-cabal" configure --with-ghc="/home/teeler/Downloads/ghc-7.0.2/inplace/bin/dummy-ghc" --with-ghc-pkg="/home/teeler/Downloads/ghc-7.0.2/inplace/bin/ghc-pkg" --with-gcc="/some/weird/bin/gcc" --configure-option=--with-cc="/some/weird/bin/gcc" --enable-library-for-ghci --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " -- dist-install libraries/terminfo I need to add some extra options to the configure command here.

1 1

semaphore functions in the wrong place during cross-build
by Tyler Pirtle 07 Mar '11

07 Mar '11

Hi, I'm not sure where the right place is to configure this. While linking hsunix + some others, the compiler assumes that -lrt is the appropriate library to find semaphore-related functions, but for the particular toolchain i'm building against, those functions are actually in -lpthread. Is there an easy way i can configure this? Thanks.

3 4

[igouy2@yahoo.com: fyi benchmarks game GHC 7.0.2]
by Don Stewart 04 Mar '11

04 Mar '11

----- Forwarded message from Isaac Gouy <igouy2(a)yahoo.com> ----- Date: Fri, 4 Mar 2011 09:11:16 -0800 (PST) From: Isaac Gouy <igouy2(a)yahoo.com> To: Don Stewart <dons(a)galois.com> Subject: fyi benchmarks game GHC 7.0.2 Hi A couple of the measurement differences to GHC 7.0.1 look strange, just letting you know. fannkuchredux,ghc,3 fasta,ghc,1 http://alioth.debian.org/scm/viewvc.php/shootout/website/websites/u64q/data… best wishes, Isaac ----- End forwarded message -----

1 0

problem running ghc-api code in ghci 7.0.x
by Daniel Gorín 02 Mar '11

02 Mar '11

Hi I have code using the ghc-api that could be run in interactive mode prior to version 7 but now makes ghci crash with a linker error. Everything works fine if compiled before running. I don't know if this is a known issue or if I'm just using the api in the wrong way, but I thought that I might ask. To illustrate the problem, consider this simple example: t.hs: > import qualified GHC > import qualified GHC.Paths > > main = GHC.runGhcT (Just GHC.Paths.libdir) $ do > -- begin initialize > df0 <- GHC.getSessionDynFlags > let df1 = df0{GHC.ghcMode = GHC.CompManager, > GHC.hscTarget = GHC.HscInterpreted, > GHC.ghcLink = GHC.LinkInMemory, > GHC.verbosity = 0} > _ <- GHC.setSessionDynFlags df1 > -- begin reset > GHC.setContext [] [] > GHC.setTargets [] > _ <- GHC.load GHC.LoadAllTargets > return () I then see: # ghci-6.12.1 -package ghc t.hs GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. [...] Loading package ffi-1.0 ... linking ... done. [1 of 1] Compiling Main ( dint.hs, interpreted ) Ok, modules loaded: Main. *Main> main Loading package ghc-paths-0.1.0.6 ... linking ... done. *Main> # ghci-7.0.1 -package ghc t.hs GHCi, version 7.0.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. [...] Loading package ffi-1.0 ... linking ... done. [1 of 1] Compiling Main ( dint.hs, interpreted ) Ok, modules loaded: Main. *Main> main Loading package ghc-paths-0.1.0.8 ... linking ... done. GHCi runtime linker: fatal error: I found a duplicate definition for symbol ___stginit_ghczmprim_GHCziBool whilst processing object file /Library/Frameworks/GHC.framework/Versions/7.0.1-i386/usr/lib/ghc-7.0.1/ghc-prim-0.2.0.0/libHSghc-prim-0.2.0.0.a This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. # ghc-7.0.1 --make -package ghc t.hs [1 of 1] Compiling Main ( t.hs, t.o ) Linking t .. # ./t # (that is, no error) I'm using ghc for mac (intel 32 bits), downloaded in binary form from the ghc page. Thanks, Daniel

1 0

testing 7.02-candidate
by Serge D. Mechveliani 02 Mar '11

02 Mar '11

This is to add to my last letter. It is curious that this 7.02 candidate stucks at оverlapping instances only when compiling the test: T_cubeext.hs:143:9: Overlapping instances for LinSolvRing (UPol k) arising from a use of `ct' ... In earlier versions, if any of them stuck at оverlapping instances, the report was earlier, when compiling the DoCon library. ----------- Mechveliani

1 0

Faster Array#/MutableArray# copies
by Johan Tibell 01 Mar '11

01 Mar '11

Hi, Daniel Peebles has done a great job adding new primops for copying arrays (both Array# and MutableArray#). This gave me a nice speedup for my hash-array mapped trie (HAMT) data structure, which is now about as fast as Data.Map for inserts but about 5.5x faster for lookups. (It should also have a lower per key/value overhead.) However, for the HAMT is more than twice as slow for inserts compared to IntMap and copying arrays is still the bottleneck. C compilers, like gcc, go to great lengths making memcpy fast and I was thinking that we might be able to steal a trick or two from them. I'd like some feedback on these ideas: * Could we try to make the array primops inline? If so, would that mean that if e.g. the number of elements to copy is known at the (Haskell) call site it would also be known in C-- and we could get the benefits of knowing that? * Could we use built-in compiler rules to catch array copies of known length and replace them with e.g. unrolled loops? My particular use case involves copying small arrays (size: 1-32). Ideally this should be as fast as copying a tuple of the corresponding size but I'm pretty sure we're far off that goal. * Can we use SSE instructions? * Can we get the C memcpy code inlined into the C-- source (crazy, I know). If so we could perhaps benefit directly from optimizations in libc. Johan

7 12

SMP parallelism gains inferior than expected
by José Pedro Magalhães 01 Mar '11

01 Mar '11

Hi, I have a program that computes a matrix of Floats of m rows by n columns. Computing each Float is relatively expensive. Each line is completely independent of the others, so I thought I'd try some simple SMP parallelism on this code: myFun :: FilePath -> IO () myFun fp = do fs <- readDataDir fp let process f = readFile' f >>= parse printLine = putStrLn . foldr (\a b -> show a ++ "\t" ++ b) "" runDiff l = [ [ diff x y | y <- l ] | (x,i) <- zip l (map getId fs), myFilter i ] ps <- mapM process fs sequence_ [ printLine x | x <- runDiff ps *`using` parList rdeepseq* ] So, I'm using parList to evaluate the rows in parallel, and fully evaluating each row. Here are the timings on a Dual Quad Core AMD 2378 @2.4 GHz, ghc-6.12.3, parallel-2.2.0.1: -N time (ms) none 1m50 2 1m33 3 1m35 4 1m22 5 1m11 6 1m06 7 1m45 The increase at 7 is justified by the fact that there were two other processes running. I don't know how to justify the small increase at N3, though, but that doesn't matter too much. The problem is that I am not getting the gains I expected (halving at N2, a third at N3, etc.). Is this the best one can achieve with this implicit parallelism, or am I doing something wrong? In particular, is the way I'm printing the results at the end destroying potential parallel gains? Any insights on this are appreciated. Thanks, Pedro

2 2

ghc-pkg regression (or deliberate change)?
by Tyler Pirtle 01 Mar '11

01 Mar '11

Hi there, I'm using a system with an older version of GHC (6.8.3), and invoking ghc-pkg against a non-existing file in -f: $ haskell/ghc/v683/k8/lib/ghc-6.8.3/ghc-pkg.bin --global-conf haskell/ghc/v683/k8/lib/ghc-6.8.3/package.conf -f /tmp/nonexistent.Foo.package.conf register /tmp/Foo.package_spec ghc-pkg happily creates the file referenced with -f and fills it with these contents: [InstalledPackageInfo {package = PackageIdentifier {pkgName = "hsS-SFoo", pkgVersion = Version {versionBranch = [1,0], versionTags = []}}, license = AllRightsReserved, copyright = "", maintainer = "", author = "", stability = "", homepage = "", pkgUrl = "", description = "", category = "", exposed = False, exposedModules = [], hiddenModules = [], importDirs = [], libraryDirs = [], hsLibraries = [], extraLibraries = [], extraGHCiLibraries = [], includeDirs = [], includes = [], depends = [], hugsOptions = [], ccOptions = [], ldOptions = [], frameworkDirs = [], frameworks = [], haddockInterfaces = [], haddockHTMLs = []} ] GHC 7.0.1 it appears does not do the same thing: $ haskell/ghc/v701/k8/lib/ghc-7.0.1/ghc-pkg --global-conf haskell/ghc/v701/k8/lib/ghc-7.0.1/package.conf.d -f /tmp/nonexistent.Foo.package_conf --force register /tmp/Foo.package_spec ghc-pkg: .../bin/hs/Foo.package_conf: openFile: does not exist (No such file or directory) (paths have been mangled by hand). ghc-pkg in 6.8.3 does what it does even without using --force. What am i missing in 7.0.1? Is this a bug or is this intentional? Thanks, Tyler

2 1