RE: Profiling trouble
From: Ferenc Wagner [mailto:[EMAIL PROTECTED]] ... 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. * ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Profiling trouble
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: -imsec 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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Profiling trouble
Simon Marlow [EMAIL PROTECTED] writes: Both of these bugs were fixed in 5.04.2. Great. 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. It's clear. The disappointing thing was to find truncated names in the .hp file, too... Btw, a wonderful XML tool is coming, isn't it? :) Till then, a switch would be more than enough. The .prof file also helps. And the letters could be smaller, and the text could be wrapped, and... For a screen view (I've never printed a profile) almost everything will do. 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. On the other hand, I've already found the problem with my code (the heap profiler helped much), so I'm coding away happily! Thanks for the good work! Feri. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghc/cygwin filename resolution issue.
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:[EMAIL PROTECTED]] | Sent: 29 January 2003 16:29 | To: [EMAIL PROTECTED] | 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 | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users | ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc/cygwin filename resolution issue.
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. Following the worse-is-better approach, here's some text for others to fiddle with (I'd recommend to keep the result in the GHC FAQ proper, possibly with a link from the building guide, if necessary). I've omitted the build-ghc-with-cygwin option, lest readers in search or solutions rush of to cause themselves even more problems;-). Cheers, Claus Using GHC (and other GHC-compiled executables )with cygwin [background] The cygwin tools aim to provide a unix-style API on top of the windows libraries, to facilitate ports of unix software to windows. To this end, they introduce a unix-style directory hierarchy under some root directory (typically / is C:\cygwin\). Moreover, everything built against the cygwin API (including the cygwin tools and programs compiled with cygwin's ghc) will see / as the root of their file system, happily pretending to work in a typical unix environment, and finding things like /bin and /usr/include without ever explicitly bothering with their actual location on the windows system (probably C:\cygwin\bin and C:\cygwin\usr\include). [the problem] GHC, by default, no longer depends on cygwin, but is a native windows program. It is built using mingw, and it uses mingw's ghc while compiling your Haskell sources (even if you call it from cygwin's bash), but what matters here is that - just like any other normal windows program - neither GHC nor the executables it produces are aware of cygwin's pretended unix hierarchy. GHC will happily accept either '/' or '\' as path separators, but it won't know where to find /home/joe/Main.hs or /bin/bash or the like. This causes all kinds of fun when GHC is used from within cygwin's bash, or in make-sessions running under cygwin. [things to do] 0) don't panic! 1) don't use absolute paths in make, configure co if there is any chance that those might be passed to GHC (or to GHC-compiled programs). Relative paths are fine because cygwin tools are happy with them and GHC accepts '/' as path-separator. And relative paths don't depend on where cygwin's root directory is located, or on which partition or network drive your source tree happens to reside, as long as you 'cd' there first. 2) if you have to use absolute paths (beware of the innocent-looking ROOT=`pwd` in makefile hierarchies or configure scripts), cygwin provides a tool called 'cygpath' that can convert cygwin's unix-style paths to their actual windows-style counterparts. Many cygwin tools actually accept absolute windows-style paths (remember, though, that you either need to escape '\' or convert '\' to '/'), so you should be fine just using those everywhere. If you need to use tools that do some kind of path-mangling that depends on unix-style paths (one fun example is trying to interpret ':' as a separator in path lists..), you can still try to convert paths using cygpath just before they are passed to GHCfriends. 3) if you don't have cygpath, you probably don't have cygwin and hence no problems with it.. unless you want to write one build process for several platforms. Again, relative paths are your friend, but if you have to use absolute paths, and don't want to use different tools on different platforms, you can simply write a short Haskell program to print the current directory (thanks to George Russell for this idea): compiled with GHC, this will give you the view of the file system that GHC depends on (which will differ depending on whether GHC is compiled with cygwin's gcc or mingw's gcc or on a real unix system..) - that little program can also deal with escaping '\' in paths. Apart from the banner and the startup time, something like this would also do: $ echo Directory.getCurrentDirectory = putStrLn . init . tail . show | ghci 4) panic now. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc/cygwin filename resolution issue.
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 I'll definitely defer to Claus on this one. I'm still working through the issues in places, but I don't yet have anything coherent to add. (This was all motivated, btw, by trying to build HaXml under ghc/cygwin, which fell for me at the first hurdle of first catch your hmake in the recipe. I've now gotten as far as a _build_ of hmake, but it then runs into similar issues with its own use of the f/s (rc files and what-not). If anyone has this one down pat already, they might save my tired brain some pain, otherwise I'll summarise to the list if and when I get some sort of resolution myself.) Cheers, Alex. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug in GHC 5.04.2 for Mac OS X
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 GPR13Bug.tar.gz Description: Binary data
