- Glasgow-haskell-users

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

Re: ghc/cygwin filename resolution issue.
by George Russell 29 Jan '03

29 Jan '03

Alex wrote [snip] > Using ghc-5.04.2 under cygwin, and cygwin (v. 1.3.10-1), I'm having some > horrible problems with inconistent treatment of filenames, especially > when using (gnu, cygwin) make. In a nutshell, make seems to be passing > paths such as "/usr/local/hmake" (etc) to ghc, which is, as I understand > it, interpretting these in a manner consistent with windows, but not with > cygwin. (i.e., it'd expect the above to be something like: > /cygwin/usr/local/hmake, where the root of the cygwin installation is in > c:\cygwin. Experimenting with similar arguments to ghc by hand seems to > confirm this. [snip] The UniForM/HTk distribution includes the attached very simple Haskell98 program, which is compiled and run during the ./configure stage. This program transforms stdin to stdout, globally replacing the string "#PWD" with whatever GHC thinks the current directory is called. This program is used in various ways; in particular ./configure uses it to set a variable GHCTOP corresponding to GHC's name for the top of the source distribution, which is then what gets passed to GHC. The program is also used for various unholy tricks involving package config files, which also of course need the Windows name. Fortunately GHC doesn't mind if some slashes are the wrong way; thus if GHCTOP is "C:\foo\bar\uni", then I can refer to "C:\foo\bar\uni\baz" as $GHCTOP/baz, as it would be on Unix. {- This program converts stdin to stdout. It replaces all occurrences of the string "#PWD" in stdin with the current directory in which it is executed, C escaped. The string "#pwd" is similarly replaced, except that it is not escaped. Everything else is left unchanged. If an argument is supplied, this is used instead of the current directory. The program occupies an unusual place in the UniForM sources; it is not part of the main sources, but is only used during building (see suffix.mk) and is compiled during configuration. Since it only uses completely standard Haskell 98, this ought to be pretty easy. We do things this way rather than with some sort of script so that this will work even in the extremely hostile environment of Windows (with no cygwin). Also, using GHC's getCurrentDirectory means we get at what GHC thinks the current directory is (IE the Windows file name) rather than what it is in cygwin's Unix world. -} module Main (main) where import Directory import System main :: IO () main = do input <- getContents args <- getArgs toInsert <- case args of [arg] -> return arg [] -> getCurrentDirectory let escapeString s = let withQuotes @ ('\"':rest) = show s in take (length rest - 1) rest quoted = escapeString toInsert transform [] = [] transform ('#':'P':'W':'D':rest) = quoted ++ transform rest transform ('#':'p':'w':'d':rest) = toInsert ++ transform rest transform (c:rest) = c:transform rest putStr . transform $ input

1 0

RE: ghc/cygwin filename resolution issue.
by Simon Marlow 29 Jan '03

29 Jan '03

> {another candidate for the ghc faq?-} By all means - or possibly the section of the Building Guide devoted to Win32 builds. Would anyone like to write a concise description of the filename issues on Windows/cygwin/GHC for the docs? I'm certainly not an expert here, but I believe the problems stem from trying to use pathnames that have special meaning to cygwin tools. GHC is not built with cygwin (at least not by default) so there's no special pathname processing going on except that '/' is accepted instead of '\', IIRC. I don't think you have to install cygwin in C:\. At least, my installation is under C:\cygwin, and I'm pretty sure it worked to build GHC last time I tried. Cheers, Simon

1 0

RE: forcing a haskell object to WHNF from C
by Simon Marlow 29 Jan '03

29 Jan '03

> 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. rts_eval() is the right way to do it, but it isn't particularly lightweight: it creates a new thread to do the evaluation. I imagine you could have a special-purpose thread that you keep around purely for doing these evaluations, if efficiency is important to you. Cheers, Simon

1 0

GHC doesn't compile under cygwin
by Chris Clearwater 28 Jan '03

28 Jan '03

Hi, today I installed cygwin and downloaded the GHC source, however during compilation I get the errors: test: 504: unknown operand test: 500: unknown operand test: 504: unknown operand In addition,I get many Error [127] (ignored) and Error [1] (ignored) before finally quiting with the unknown operand errors. Attached is the configure output, confiure log and make output. Thanks in advance for any help.

1 0

ghc/cygwin filename resolution issue.
by Alex Ferguson 28 Jan '03

28 Jan '03

Using ghc-5.04.2 under cygwin, and cygwin (v. 1.3.10-1), I'm having some horrible problems with inconistent treatment of filenames, especially when using (gnu, cygwin) make. In a nutshell, make seems to be passing paths such as "/usr/local/hmake" (etc) to ghc, which is, as I understand it, interpretting these in a manner consistent with windows, but not with cygwin. (i.e., it'd expect the above to be something like: /cygwin/usr/local/hmake, where the root of the cygwin installation is in c:\cygwin. Experimenting with similar arguments to ghc by hand seems to confirm this. Is there a work-around for this, or is using cygwin and ghc together just an out and out bad idea? Cheers, Alex.

3 2

RE: Profiling trouble
by Simon Marlow 28 Jan '03

28 Jan '03

> With 5.04 I get almost the same, look: > > COST CENTRE MODULE %time %alloc > > showData1 Main 87.1 89.2 > ncEps Epsilon 3.6 3.4 > cutAbove4 Tcsa 2.6 1.2 > > > individual inherited > COST CENTRE MODULE no. entries %time > %alloc %time %alloc > > MAIN MAIN 1 0 0.0 > 0.0 100.0 100.0 > main Main 165 0 0.1 > 0.0 100.0 100.0 > [...] > showData Main 173 1 0.0 > 0.0 91.5 92.1 > showData2 Main 178 0 0.0 > 0.0 0.0 0.0 > showData3 Main 177 0 0.0 > 0.0 0.0 0.0 > showData4 Main 176 0 0.1 > 0.1 0.1 0.1 > showData5 Main 175 0 0.0 > 0.0 0.3 0.3 > myShow Main 200 9453 0.3 > 0.3 0.3 0.3 > showData1 Main 174 0 87.1 > 89.2 91.1 91.7 > cutAbove Tcsa 181 0 0.0 > 0.0 2.6 1.2 > cutAbove2 Tcsa 199 1 0.0 > 0.0 0.0 0.0 > cutAbove3 Tcsa 193 27 0.0 > 0.0 0.0 0.0 > cutAbove4 Tcsa 182 0 2.6 > 1.2 2.6 1.2 > spinSelect Tcsa 180 1 0.0 > 0.0 0.0 0.0 > getStates Tcsa 179 1 0.9 > 1.0 1.4 1.2 > incrementalBase Fermion 189 1 0.4 > 0.2 0.5 0.2 > fermionNumber Fermion 192 77664 0.1 > 0.0 0.1 0.0 > mergeUp Boson 184 6 0.0 > 0.0 0.0 0.0 > allTowers Boson 183 0 0.0 > 0.0 0.0 0.0 > inModule Boson 185 17 0.0 > 0.0 0.0 0.0 > [...] It looks from the profile that the showData1 cost centre has widened in scope to encompass some extra code. This may be because of incorrect transformations made by the compiler (transformations in the presence of cost-centre annotations have to be done very carefully, and I'm sure the compiler currently has bugs in this area). If you could send us a smaller example that displays the problem, we'll be happy to look into it. Cheers, Simon

2 2

RE: problem using ffi with profiling
by Simon Marlow 27 Jan '03

27 Jan '03

> Sure. The relevant files look like: [... snipped ...] -prof automatically turns on -fvia-C (because the native code generator can't generate code for profiling), so I'm guessing that -prof is a red herring and you'll get the same result if you just turn on -fvia-C. When compiling with the native code generator, any include files specified in FFI declarations or with -#include options are ignored. Perhaps you need to add an appropriate -I flag to the command line so the C compiler can find the header files? Cheers, Simon

2 1