February 2005 - Glasgow-haskell-users

RE: debugging memory allocations
by Simon Marlow 07 Feb '05

07 Feb '05

On 02 February 2005 18:42, Duncan Coutts wrote: > On Wed, 2005-02-02 at 17:01 +0000, Simon Marlow wrote: >> On 02 February 2005 13:38, Duncan Coutts wrote: >>> Would looking at the core files help? What would I be looking for? >>> >>> Here's a simple version that I would expect to run in constance >>> space. >>> >>> pixbufSetGreen :: Pixbuf -> IO () >>> pixbufSetGreen pixbuf = do >>> ptr <- pixbufGetPixels pixbuf >>> sequence_ >>> [ do pokeByteOff ptr (y*384+3*x) (0 ::Word8) >>> pokeByteOff ptr (y*384+3*x+1) (128::Word8) >>> pokeByteOff ptr (y*384+3*x+2) (96 ::Word8) | y <- >>> [0..127] , x <- [0..127] ] >>> >> >> Yes, let's see the core. Since you're interested in allocation, you >> might be better off with -ddump-prep rather than -ddump-simpl: the >> former has all the allocation made into explicit 'let' expressions >> ready for code generation. > > Ok, attached it the -ddump-prep for the version using pixbufSetGreen, > and another file for the longer more complicated one which is using > setWierdColour. Both versions do contain 'let's. > > I've also attached the original code. (which you won't be able to > build without hacking the gtk bits out of it) I took a quick look at this, and one thing I noticed is that some deforestation isn't happening. There is still an explicit [0..127] being constructed/deconstructed. I don't think we'll be able to investigate this right now, so if you need performance immediately I suggest you rewrite the code using explicit recursion. Cheers, Simon

1 0

STM check/MonadPlus
by Remi Turk 06 Feb '05

06 Feb '05

Hi, I have a few questions about the `check' function from Control.Concurrent.STM. First, in the paper its definition contains a (type) error: check :: Bool -> STM a check True = return () check False = retry in fptools, however, it is defined as follows: check :: Bool -> STM a check b = if b then return undefined else retry As we already have guard, and STM is an instance of MonadPlus, I wonder why such a simple utility function as check is wanted at all. guard :: (MonadPlus m) => Bool -> m () guard True = return () guard False = mzero Greetings, Remi -- Nobody can be exactly like me. Even I have trouble doing it.

1 0

installing current binary distribution
by Alain Cremieux 04 Feb '05

04 Feb '05

> > >Hi, > >I've installed ghc-6.3.20050202-i386-unknown-linux.tar.bz2 only to find >out that gcc-3.4.1 seems to be hard-wired into this ghc: > >ghc-6.3.20050202: could not execute: gcc-3.4.1 > >Why is this so. Do I need to install from sources? My current gcc >version is: > >gcc (GCC) 3.3.1 (SuSE Linux) > >Cheers Christian > > > I had this problem once, and solved it simply by creating a symbolic link gcc-3.4.1 towards my version of gcc (3.2.2), and everything worked OK. Alain > ------------------------------------------------------------------------

1 0

RE: installing current binary distribution
by Simon Marlow 04 Feb '05

04 Feb '05

On 04 February 2005 12:23, Christian Maeder wrote: > I've installed ghc-6.3.20050202-i386-unknown-linux.tar.bz2 only to > find out that gcc-3.4.1 seems to be hard-wired into this ghc: > > ghc-6.3.20050202: could not execute: gcc-3.4.1 > > Why is this so. Do I need to install from sources? My current gcc > version is: > > gcc (GCC) 3.3.1 (SuSE Linux) This is because we currently configure the nightly builds to use gcc-3.4.1, and unfortunately that gets baked into the GHC binary. You can compile from source to get around this. The STABLE snapshots don't have this problem. Cheers, Simon

2 2

installing current binary distribution
by Christian Maeder 04 Feb '05

04 Feb '05

Hi, I've installed ghc-6.3.20050202-i386-unknown-linux.tar.bz2 only to find out that gcc-3.4.1 seems to be hard-wired into this ghc: ghc-6.3.20050202: could not execute: gcc-3.4.1 Why is this so. Do I need to install from sources? My current gcc version is: gcc (GCC) 3.3.1 (SuSE Linux) Cheers Christian

1 0

RE: RFC: hyperlinks in Haddock docs
by Simon Marlow 04 Feb '05

04 Feb '05

On 02 February 2005 12:22, Ross Paterson wrote: > On Tue, Feb 01, 2005 at 11:02:45AM -0000, Simon Marlow wrote: >> So the new approach is to try to build up a global table of the >> "best" destinations to link to for each entity. > > Having a canonical home location for each entity might also help with > another bugbear with Haddock: determining whether two unqualified > names refer to the same entity. This is impossible at present > because Haddock doesn't show qualified names (because doing so would > be too cumbersome) and anyway the defining module is often hidden. > It's not clear which of the documented catch functions are > Control.Cuncurrent.catch, and which are System.IOError.catch. With > the new scheme, documentation for an entity in a module other than > its home could include a cross-reference to its home. This is a good idea, I've put it on the TODO list. Cheers, Simon

1 0

RE: Waiting on Sockets or File Descriptors
by Simon Marlow 03 Feb '05

03 Feb '05

On 02 February 2005 19:48, Peter Simons wrote: > Wolfgang Thaller writes: > > > a) poll() is not supported on Mac OS X and (at least some > > popular versions of) BSD. > > Are you certain? Just tried "man poll" on one of the MacOS X > machines the SourceForge compile farm offers, and that one > had it: "Darwin ppc-osx1 5.5 Darwin Kernel Version 5.5". > > > > b) 'forkIO' in the threaded RTS would suffice in this > > case, as the poll() or select() system calls don't use > > any thread-local state. In the threaded RTS, "safe" > > foreign imports never affect other threads [...]. > > That would be really good news! I assumed that GHC's runtime > system used one thread for _all_ FFI invocations? (Unless > you start new ones.) So I thought calling poll() would block > all other FFI invocations until it returned? > > Or is that only for "unsafe" FFI calls? When you compile your program with -threaded, "safe" FFI calls don't block other threads, but "unsafe" calls still do. Basically a "safe" FFI call releases the lock on the RTS so other Haskell threads can continue to run (and that at least partly explains why we have the distinction: releasing and re-acquiring a lock is expensive). > Do you have an URL for me where I can find out more about > this, by any chance? There's not much, but the -threaded option is documented here: http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.h tml#OPTIONS-LINKER and the Control.Concurrent documentation explains what "bound" threads are. Cheers, Simon

4 3

RE: debugging memory allocations
by Simon Marlow 03 Feb '05

03 Feb '05

On 03 February 2005 00:41, Duncan Coutts wrote: > On Wed, 2005-02-02 at 13:30 -0700, Seth Kurtzberg wrote: >> Duncan Coutts wrote: >>> In these cases we cannot turn on traditional profiling since that >>> would interfere with the optimisations we are relying on to >>> eliminate most of the other memory allocations. >>> >> I don't understand why you can't use profiling as a debugging tool. >> How would profileing, ifor test purposes, cause other things to >> break? > > The problem is that profiling add in extra parameters and extra code > to each function (each SCC). This can interfere with optimisations > like inlining and unboxing I believe. Simon could explain it better. Yes. Those pesky SCC annotations get in the way of optimisations. It's possible (likely even) that we could do a better job here, profiling is long overdue for an overhaul. Cheers, Simon

1 0

Waiting on Sockets or File Descriptors
by Peter Simons 02 Feb '05

02 Feb '05

Hi, I have the following problem: I use an external library through the foreign function interface which gives me _several_ sockets and expects me to call it again when any of those sockets becomes readable or writable. Since I know that the Haskell run-time system has all the required functionality in place, I wonder whether there is any way to register these sockets in the internal scheduler and have it call an 'IO ()' function in case of such an event? What makes matters more complicated is that the _library_ owns these sockets -- not me. So I cannot really touch them or lift them into a 'Handle'. Any ideas? Peter

4 7

RE: debugging memory allocations
by Simon Marlow 02 Feb '05

02 Feb '05

On 02 February 2005 13:38, Duncan Coutts wrote: > I'm looking for advice on how to figure out why some piece of code is > allocating memory when I think it ought to be able to work in constant > space. > > In these cases we cannot turn on traditional profiling since that > would > interfere with the optimisations we are relying on to eliminate most > of > the other memory allocations. > > Would looking at the core files help? What would I be looking for? > > Here's a simple version that I would expect to run in constance space. > > pixbufSetGreen :: Pixbuf -> IO () > pixbufSetGreen pixbuf = do > ptr <- pixbufGetPixels pixbuf > sequence_ > [ do pokeByteOff ptr (y*384+3*x) (0 ::Word8) > pokeByteOff ptr (y*384+3*x+1) (128::Word8) > pokeByteOff ptr (y*384+3*x+2) (96 ::Word8) > | y <- [0..127] > , x <- [0..127] ] > > (Don't worry about all those random constants, it's just test code!) Yes, let's see the core. Since you're interested in allocation, you might be better off with -ddump-prep rather than -ddump-simpl: the former has all the allocation made into explicit 'let' expressions ready for code generation. Cheers, Simon

2 1