January 2003 - Glasgow-haskell-users

RE: openFile and threads
by Simon Marlow 07 Feb '03

07 Feb '03

> Now I'm wondering about ways to cut that down: > 1. How can I avoid the allocations inside of openFile? > 2. Would it help to call f6 in different threads? That is, does a > thread yield when it calls an IO function? openFile is quite expensive because it normally allocates a buffer, which I suspect accounts for most of the allocation you're seeing. It also sets up a finalizer, allocates the Handle, and does a couple of extra system calls. If the openFile isn't on the critical path, then it can help to do it in another thread, but only if the openFile is blocking (not usually the case if you're opening a normal file). You might consider bypassing the Handle interface and going to the bare metal using the Posix library, which will cut down on the overhead in openFile. The best solution is to avoid the open altogether if possible (eg. with caching), but I don't know about your particular application so this might not be a possibility. Cheers, Simon

4 4

RE: ghc/cygwin filename resolution issue.
by Simon Peyton-Jones 03 Feb '03

03 Feb '03

Alex As Simon M says, if you (or anyone else) felt able to write up a standalone summary of what the problem is, and what the solution is, I'd love to add it to the GHC FAQ or documentation somewhere. In my experience, simply explaining the problem clearly is quite tricky. (E.g. the cygwin vs mingw issues, described in the Building Guide, took me ages to understand well enough to write down.) Simon | -----Original Message----- | From: Alex Ferguson [mailto:abf@cs.ucc.ie] | Sent: 29 January 2003 16:29 | To: glasgow-haskell-users(a)haskell.org | Subject: Re: ghc/cygwin filename resolution issue. | | | | Thanks to all for the replies; Hal's resolution rings a | bell, now that I think about it, from Ye Olde Days when | cygwin was a ghc pre-req -- just didn't think of it when | installing more recently on a new machine. (Install in | haste, repent at leisure.) Claus' suggestion about relative | paths does the ticket, though: didn't occur to me as the | paths were being generated by a configure script, but yes, it | was possible to override them, which works as advertised. | | Cheers, | Alex. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

4 3

Re: Calling ghc dll's with MSVC++ code
by Kevin S. Millikin 31 Jan '03

31 Jan '03

Hmmm, I just now came across this: "I'm not confident that creating Haskell DLLs is working at the moment. Has anyone else done it?" I have. Or rather, I haven't. The example in Section 11.4 of the User's Guide doesn't work. The call to "startupHaskell()" hangs forever (or as long as I'm willing to wait). It works fine when the exact same call to startupHaskell is linked statically. "Trouble is, there isn't yet a critical mass of DLL users to be sure that it works and stays working. Which is a bit of a chicken and egg problem. Windows programmers unite!" Is two a critical mass? -- Kevin S. Millikin Architecture Technology Corporation Research Scientist Specialists in Computer Architecture (952)829-5864 x. 162 http://www.atcorp.com

2 3

Re: Bug in GHC 5.04.2 for Mac OS X
by Ashley Yakeley 31 Jan '03

31 Jan '03

At 2003-01-30 20:27, I wrote: >GPR13 is indeed considered nonvolatile, so it looks like the JVM is >correct and the function made by createAdjustor is wrong. See enclosed example. -- Ashley Yakeley, Seattle WA

2 1

Bug in GHC 5.04.2 for Mac OS X
by Ashley Yakeley 30 Jan '03

30 Jan '03

At 2002-12-08 02:52, Wolfgang Thaller wrote: >A Mac OS X installer package is now available at >http://www.uni-graz.at/imawww/haskell/GHC.5.04.2.dmg I seem to be having trouble with 'foreign import ccall "wrapper"' functions. It was crashing in combination with the Java VM: examination with gdb revealed that the function created with 'foreign import ccall "wrapper"' was changing register r13, and it looks like the JVM code that called it was expecting r13 to be preserved. This appears to be a bug in GHC for Mac OS X. $ ghc --version The Glorious Glasgow Haskell Compilation System, version 5.04.2 $ uname -a Darwin Ashley-Yakeleys-Computer.local. 6.3 Darwin Kernel Version 6.3: Sat Dec 14 03:11:25 PST 2002; root:xnu/xnu-344.23.obj~4/RELEASE_PPC Power Macintosh powerpc -- Ashley Yakeley, Seattle WA

1 1

RE: Profiling trouble
by Simon Marlow 30 Jan '03

30 Jan '03

> something interesting turned up again. Setting cut=8 in > Show2.hs and running it with ./show +RTS -h -i0.01 gives > > show: fatal error: main thread has been GC'd > > It may be silly, since 0.01 < 1/50, but this error message > isn't too helpful. Btw, +RTS -? says: > > -i<msec> Time between heap samples (msec, default: 100) > > which is wrong (time is given in seconds really). Both of these bugs were fixed in 5.04.2. > One more question: is there a way not to truncate the call > stacks? Ie in the hp file I see lines like > > (144)showData2/showData/ma... 12 > > and I'd like to see showData2/showData/main or so. I'm afraid there's no way at the moment, but I'll look into adding a flag. The problem is that the longer the stacks get, the less room there is for the graph - hp2ps tends to squeeze the graph up to make room for the labels, which is why we truncate them. Your other problem (misattribution of costs in the profile) seems to be related to the use of overloaded functions, and the compiler isn't translating the definition of getStates properly. I haven't found a fix yet. Cheers, Simon

2 1

RE: Profiling trouble
by Simon Marlow 30 Jan '03

30 Jan '03

> I'm also having some fun with profiling... > > First: > The GHC manual might want to mention that running ghc --show-iface > on an interface file won't work if it was compiled with -prof. > You get: "mismatched interface file versions: expected 5042, > found 5042p" > Compiling sans -prof works. This bug has been fixed. > Second: > Heap profiling falls over (seg fault) in some cases unless I > compile with -O2. This is a bug - could you provide us with the source and instructions to reproduce? > Third: > How do I tell if my functions are strict or not? > The manual says: > "Look for your function in the interface file, then for the > third field in > the pragma; it should say __S <string>. The <string> gives > the strictness of > the function's arguments. L is lazy (bad), S and E are strict > (good), P is > primitive (good), U(...) is strict and unpackable (very > good), and A is > absent (very good)." To see the pragmas, you need to compile the module with -O. You can view the interface with --show-iface. For example, here's 'not' from the Prelude: 1 not :: Bool -> Bool {-## __A 1 __C __S S __U (\ ds :: Bool -> case ds of wild {False -> $wTrue; True -> $wFalse;}) ##-}; You can see that strictness pragma (following __S) is "S", which means the function is strict in its single argument. Cheers, Simon

1 0

RE: Profiling trouble
by Bayley, Alistair 30 Jan '03

30 Jan '03

> From: Ferenc Wagner [mailto:wferi@tba.elte.hu] > ... > One more question: is there a way not to truncate the call > stacks? Ie in the hp file I see lines like > > (144)showData2/showData/ma... 12 > > and I'd like to see showData2/showData/main or so. hear, hear... I'm also having some fun with profiling... First: The GHC manual might want to mention that running ghc --show-iface on an interface file won't work if it was compiled with -prof. You get: "mismatched interface file versions: expected 5042, found 5042p" Compiling sans -prof works. Second: Heap profiling falls over (seg fault) in some cases unless I compile with -O2. Cost-centre profiling works in both cases, and reveals that without -O2, a lot more heap is used: Sans -O2: queens +RTS -p -RTS total time = 28.42 secs (1421 ticks @ 20 ms) total alloc = 791,617,668 bytes (excludes profiling overheads) Avec -O2: queens +RTS -p -hc -RTS total time = 21.28 secs (1064 ticks @ 20 ms) total alloc = 464,256,564 bytes (excludes profiling overheads) I suspect that using a lot of heap causes it to fall over. (My program is called queens because I'm trying to solve the Queens and Knights problem on this page: http://www.itasoftware.com/careers/programmers.php ) Third: How do I tell if my functions are strict or not? The manual says: "Look for your function in the interface file, then for the third field in the pragma; it should say __S <string>. The <string> gives the strictness of the function's arguments. L is lazy (bad), S and E are strict (good), P is primitive (good), U(...) is strict and unpackable (very good), and A is absent (very good)." Now, my functions weren't exported, so I've exported some of them, and used ghc -Wall -ddump-simpl -ddump-hi ... to compile, and now I get this (I've removed the Core syntax stuff, 'cos there's a lot of it): ==================== NEW FINAL INTERFACE ==================== __interface "Main" Main 1 5042 where __export Main addQueens addQueens2 allSquares eightQueens keepBoard knightsQueens main placeKnight placeQueen showBoard showBoards showRow showSquare testAndAdd; import Data.Set :: 1; import GHC.IOBase :: 1; import GHC.TopHandler :: 1; import GHC.Base ! :: 1; import GHC.Real :: 1; import GHC.Enum :: 1; import GHC.Num :: 1; import GHC.Show :: 1; import GHC.List :: 1; import System.IO :: 1; import Data.Tuple :: 1; import GHC.Ptr :: 1; import Foreign.Ptr ! :: 1; import Data.FiniteMap :: 1; ; (Main.$main) :: GHC.IOBase.IO (); Main.knightsQueens :: [Main.Board]; Main.main :: GHC.IOBase.IO (); Main.placeQueen :: Main.Board -> [Main.Coord] -> [Main.Board] -> [Main.Board]; Main.placeKnight :: Main.Board -> [Main.Coord] -> [Main.Board] -> [Main.Board]; Main.testAndAdd :: Main.Board -> [Main.Board] -> [Main.Board]; Main.keepBoard :: Main.Board -> GHC.Base.Bool; Main.allSquares :: [Main.Coord]; Main.eightQueens :: [Main.Board]; Main.addQueens :: Main.Board -> GHC.Base.Int -> [Main.Board] -> [Main.Board]; Main.addQueens2 :: Main.Board -> GHC.Base.Int -> GHC.Base.Int -> [Main.Board] -> [Main.Board]; Main.showBoards :: [Main.Board] -> GHC.Base.String; Main.showBoard :: Main.Board -> GHC.Base.String; Main.showRow :: Main.Board -> GHC.Base.Int -> GHC.Base.String; Main.showSquare :: Main.Board -> GHC.Base.Int -> GHC.Base.Int -> GHC.Base.Char; type Main.Coord = (GHC.Base.Int, GHC.Base.Int) type Main.Square = GHC.Base.Int; type Main.Squares = Data.Set.Set Main.Square; type Main.Board = (Main.Squares, Main.Squares, Main.Squares); What should I be looking for? Can/should I inspect the Core syntax too? Thanks, Alistair. ***************************************************************** The information in this email and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). This information may be subject to legal professional or other privilege or may otherwise be protected by work product immunity or other legal rules. It must not be disclosed to any person without our authority. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. *****************************************************************

1 0

Re: ghc/cygwin filename resolution issue.
by Alex Ferguson 29 Jan '03

29 Jan '03

Thanks to all for the replies; Hal's resolution rings a bell, now that I think about it, from Ye Olde Days when cygwin was a ghc pre-req -- just didn't think of it when installing more recently on a new machine. (Install in haste, repent at leisure.) Claus' suggestion about relative paths does the ticket, though: didn't occur to me as the paths were being generated by a configure script, but yes, it was possible to override them, which works as advertised. Cheers, Alex.

1 0

forcing a haskell object to WHNF from C
by Bernard James POPE 29 Jan '03

29 Jan '03

Hi all, This might seem like a strange thing to do, but ... Presume I have a HaskellObj in some C code. I know that it is a thunk. I want to force it to _WHNF_ . Should/can I use rts_eval()? Any pointers on what this does (start new threads, cause garbage collection ...) would be appreciated. I can (and have) gone over the code but a more high level description would be helpful. Or perhaps there is another/better way. In essence I want a C version of seq (perhaps I can call to Haskell to perform a seq on it, but I think this might be overkill). A lightweight solution would be nice. Cheers, Bernie.

2 1