- Glasgow-haskell-users

More speed please!
by Duncan Coutts 11 May '07

11 May '07

All, So here's the Put monad for the binary serialisation stuff: newtype Put a = Put { runPut :: (a -> Buffer -> [B.ByteString]) -> Buffer -> [B.ByteString] } data Buffer = Buffer {-# UNPACK #-} !(ForeignPtr Word8) {-# UNPACK #-} !Int -- offset {-# UNPACK #-} !Int -- used bytes {-# UNPACK #-} !Int -- length left This is all good, and pretty quick. Code like the following gets turned into great low level code: foo :: Word8 -> Put () foo !n = do word8 n word8 (n+1) word8 (n+17) It does a straight line sequence of writes into memory (there are rules that combine the bounds checking of adjacent writes). After that it calls the continuation with a new buffer. While almost everything is unboxed, the parameters to the continuation are not unboxed. So we have to allocate a new Buffer structure and pass that to the continuation: let { sat_s1F8 = NO_CCS PutMonad.Buffer! [ww1_s1Es ww2_s1Et ww3_s1Ew sat_s1F4 sat_s1F6]; } in w_s1DY GHC.Base.() sat_s1F8; w_s1DY being the continuation here. However we know that really the parameters to this continuation could really be unboxed since we construct all these continuations explicitly in this module. We could re-write the monad type by manually explicitly unboxing the Buffer argument: newtype Put a = Put { runPut :: (a -> Addr# -> ForeignPtrContents -> Int# -> Int# -> Int# -> [B.ByteString]) -> Addr# -> ForeignPtrContents -> Int# -> Int# -> Int# -> [B.ByteString] } Then we'd get no allocations and no heap checks in the fast path. Note that we could still get a continuation in from the 'outside' with the original type and convert it to one with the above type, though obviously that involves unpacking the arguments. This unpacking is basically what the wrapper of a worker/wrapper pair does of course. Obviously this is ugly. We'd much rather write the original and with just a couple annotations get the above representation. This is what I would like to write: newtype Put a = Put { runPut :: (a -> {-# UNPACK #-} !Buffer -> [B.ByteString]) -> {-# UNPACK #-} !Buffer -> [B.ByteString] } So I'm declaring a type and a data constructor that contains a function that is strict in one of it's arguments. I do not wish to distinguish the strictness in the type however, that is it should be perfectly ok to do this: foo :: Foo -> Buffer -> [B.ByteString] Put foo newBuffer :: Put Foo Suppose that in this case we do not know locally that foo is strict and can take it's args unboxed then upon applying the Put constructor we just have to apply a wrapper function that boxes up the args and supplies them to the wrapped function. Obviously that'd be a pessimisation, having to re-box args, however we can expect programmers to only use that UNPACK pragma when they know that it is going to be a win overall. So the ! on the arg is a semantic change and the pragma is a representation change but not a semantic change. The ! means the obvious thing, that the function is strict in that arg. So either the caller or calle must ensure the arg is evaluated to WHNF. Hmm, is the UNPACK actually needed then? Normally when ghc determines that a func is strict in an arg it make the worker unbox that arg if possible and that always seems to be a win. Mine you, in that case we know what the function is going to do with each arg, where as here we do not so perhaps a separate UNPACK makes sense. This issues crops up quite a bit with Monads I think. For example GHC defines it's IO monad to return an unboxed tuple: newtype IO a = IO (State# RealWorld -> (# State# RealWorld, a #)) This is fine for low level internal code, but for everyday monads it'd be nice to be able to write nice code and still get great performance. This applies to monads particularly since they very often fully encapsulate the function used as the internal representation, that is all the sites where the representation function is constructed and taken apart are in a single module. So we can 'see' that all uses are strict in some arg. Or if they're not we might want them to be. So instead of doing an analysis to figure out if we're always using it strictly (which is something that jhc/grin might be able to do?) we can just declare the data representation to be strict like we do with ordinary algebraic data types, that way it propagates strictness to the usage sites which is much more convenient than going around strictifying all the usage sites in an attempt to make an analysis notice that it's safe to do a representation change. Ok, I'm done. :-) Duncan

5 10

GHC as a library - getting output from GHCI
by Mads Lindstrøm 11 May '07

11 May '07

Hi I am trying to use GHC as a library (see http://haskell.org/haskellwiki/GHC/As_a_library ). I want to get all the output from an interactive session and put in a GUI. This http://haskell.org/sitewiki/images/5/51/Interactive.hs seemed to be a nice starting point. However, the result of: GHC.runStmt session stmt does not include the output of evaluating the statement (stmt above) - just the names of bound names. That is if stmt eqauls "3 + 5" then GHC.runStmt do not return a string equaling "8", but just the "it"-name (which is bound to 8). The output is printed to standard output :( And I do not see and easy way to get hold of it. The only way I see, is having the GUI in one process and "GHC as a library" in another process. Do anybody know of an easy way to get hold of the output from "GHC as a library" - the output currently printed to standard output? Greetings, Mads Lindstrøm

5 14

ghc-6.6.1 under i386 Solaris
by Christian Maeder 11 May '07

11 May '07

Hi, the stage2 compiler I've created from the official sources almost works, but ghci crashes with seg-fault. Any ideas? -bash-3.1$ gdb --args /localdisk/maeder/haskell/ghc-6.6.1/compiler/stage2/ghc-6.6.1 -B/localdisk/maeder/haskell/ghc-6.6.1 --interactive GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-pc-solaris2.10"... (gdb) run Starting program: /localdisk/maeder/haskell/ghc-6.6.1/compiler/stage2/ghc-6.6.1 -B/localdisk/maeder/haskell/ghc-6.6.1 --interactive warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 00000074 [New LWP 1] [New LWP 2] ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. [New LWP 3] Loading package base ... linking ... done. Program received signal SIGSEGV, Segmentation fault. 0x08cd0980 in ?? () (gdb) where #0 0x08cd0980 in ?? () #1 0x0000fd90 in ?? () #2 0xa39cbf6c in ?? () #3 0x00010980 in ?? () #4 0x00000004 in ?? () #5 0x0001433c in ?? () #6 0x08a5f448 in MainCapability () #7 0x00000001 in ?? () #8 0x08cd0980 in ?? () #9 0x9b726b40 in ?? () #10 0x9b726ab8 in ?? () #11 0x08a5f448 in MainCapability () #12 0x00000000 in ?? () (gdb) quit The program is running. Exit anyway? (y or n) y -bash-3.1$ uname -a SunOS isaac 5.10 Generic_118855-36 i86pc i386 i86pc

1 1

ghci dynamic linking
by Frederik Eaton 10 May '07

10 May '07

Hello, I am wondering how to link a package with some dynamic libraries in a way that works with ghci. If I run the command LD_PRELOAD=/lib/libgcc_s.so.1:/usr/lib/libstdc++.so.6 ghci -package mypackage then it is successful; I am able to use package mypackage in ghci. But if I omit the LD_PRELOAD=... part then ghci complains about missing symbols. How do I configure my package so that the LD_PRELOAD=... part of the command is not necessary? Thanks, Frederik

3 3

SMP question
by Cristian Perfumo 09 May '07

09 May '07

Some days ago I sent an email to the list asking about the reason why I couldn't run my programs with the "-Nx" RTS option even if I compiled them with -threaded. AH! by the way, the architecture is ia64 (Itanium). Today I realized that when I ./configure, a preprocessor variable called "NOSMP" is defined and it disallows the multiple OS threads (the -Nx option). Looking a bit deeper I figured out that there's no Itanium version for the functions xchg (exchange), cas (compare-and-swap) and write_barrier in the header file SMP.h (includes/SMP.h) so there's no way that the holy -N option is available. My question is: is it enough to implement xchg, cas and write_barrier for ia64 to make multiple OSthreads available on ia64? If not, what else should be implemented/changed? Regards. Cristian Perfumo

2 3

problems using ghc-6.6.1 (due to fgl-5.4.1)
by Christian Maeder 09 May '07

09 May '07

I wrote: > Dear Hets- and GHC-Developers, > we have a problem using ghc-6.6.1. The created hets binary runs a > couple > of times slower than the one created using ghc-6.6. This problem is gone when I install and use fgl-5.3 (where "hiding (indices)" needs to be deleted in Data.Graph.Inductive.Monad.IOArray). I strongly suspect the new functions context1l' and context4l' in Data.Graph.Inductive.Graph (fgl-5.4.1) to be the reason for our drastic slow down. In fgl-5.3 the functions fst4 and fth4 have been used instead. A cyclic edge (an edge from and to the very same node) was only returned as ingoing edge and not as outgoing one. (a design decision documented elsewhere). I think, the change in fgl-5.4.1 now returns a cyclic edge also as outgoing edge (and possibly twice as ingoing one). Our application heavily uses in- and outgoing edges that may be cyclic. Christian P.S. ghc-6.6.1/libraries/fgl/Setup.hs does not compile with ghc-6.6.1

2 2

problems using ghc-6.6.1
by Christian Maeder 09 May '07

09 May '07

Dear Hets- and GHC-Developers, we have a problem using ghc-6.6.1. The created hets binary runs a couple of times slower than the one created using ghc-6.6. (see below) What might be the cause for this? Cheers Christian ghc-6.6.1: hets +RTS -H300m -M1g -p -RTS -o prf Basic/Numbers.casl total time = 1979.05 secs (39581 ticks @ 50 ms) total alloc = 167,752,167,576 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc selectProofBasis Proofs.EdgeUtils 82.8 86.1 sl_sign CASL.Sublogic 5.3 3.7 compInclusion Logic.Grothendieck 3.2 3.2 getAllPathsOfTypesBetween Proofs.EdgeUtils 1.5 1.6 isSubOpMap CASL.Sign 1.2 0.9 primCoerce Logic.Coerce 0.8 1.1 ghc-6.6: hets +RTS -H300m -M1g -p -RTS -o prf Basic/Numbers.casl total time = 215.25 secs (4305 ticks @ 50 ms) total alloc = 20,691,103,008 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc selectProofBasis Proofs.EdgeUtils 73.1 79.6 sl_sign CASL.Sublogic 6.8 4.2 compInclusion Logic.Grothendieck 3.7 3.8 getAllPathsOfTypesBetween Proofs.EdgeUtils 2.8 3.1 isSubOpMap CASL.Sign 1.6 1.1 sublogics_join CASL.Sublogic 1.5 1.1 primCoerce Logic.Coerce 1.3 1.4 isSameTranslation Proofs.Local 1.2 0.9

3 3

Why do we have stack overflows?
by Adrian Hey 08 May '07

08 May '07

Hello Folks, Just wondering about this. Please understand I'm not asking why programs use a lot of stack sometimes, but specifically why is using a lot of stack (vs. using a lot of heap) generally regarded as "bad". Or at least it seems that way given that ghc run time makes distinction between the two and sets separate limits for them (default max stack size being relatively small whereas default max heap size in unlimited). So programs can fail with a stack overflow despite having bucket loads of heap available? Frankly I don't care if my program fails because it's used a lot of stack or a lot of heap. I would rather set some common memory budget and have them fail if that budget was exceeded. This policy seems to have unfortunate consequences. Sometimes you end up re-writing stuff in a manner that just trades stack use for heap use (I.E. doesn't do anything to reduce overall memory consumption). Given the cost of reclaiming heap is rather high (compared to stack), this seems like bad idea (the version that used a lot of stack would be better IMO if only it didn't risk stack overflow). Example.. -- Strict version of take stackGobbler :: Int -> [x] -> [x] stackGobbler 0 _ = [] stackGobbler _ [] = [] stackGobbler n (x:xs) = let xs' = stackGobbler (n-1) xs in xs' `seq` (x:xs') -- Another strict version of take heapGobbler :: Int -> [x] -> [x] heapGobbler = heapGobbler' [] where heapGobbler' rxs 0 _ = reverse rxs heapGobbler' rxs _ [] = reverse rxs heapGobbler' rxs n (x:xs) = heapGobbler' (x:rxs) (n-1) xs But I guess everyone here is already aware of this, hence the question (current ghc memory system design seems a bit odd, but maybe there's a good reason why the rts can't work the way I would like). Thanks -- Adrian Hey

8 12

Cost of Overloading vs. HOFs
by Adrian Hey 07 May '07

07 May '07

Hello, The GHC users guide says overloading "is death to performance if left to linger in an inner loop" and one thing I noticed while playing about with the AVL lib was that using a HOF and passing the (overloaded) compare function as an explicit argument at the start seemed to give noticable a performance boost (compared with dictionary passing presumably). I'm not sure why that should be, but has anyone else noticed this? If so, maybe this advice should be added to the user guide, especially if your function repeatedly uses just one method from a class? (or maybe not if it's nonsense :-) I guess having done this there would be little to gain by using the SPECIALIZE pragma though (unless ghc also specialises HOFs). Regards -- Adrian Hey

11 16

recent Windows installer for ghc head?
by Conal Elliott 04 May '07

04 May '07

I'd like to try out the new & improved combination of type classes and GADTs, which I understand is only in head. Is there a recent working windows installer for head? Thanks, - Conal

4 5