January 2005 - Glasgow-haskell-users

RE: profiling usage
by Simon Marlow 26 Jan '05

26 Jan '05

On 26 January 2005 09:13, Serge D. Mechveliani wrote: > The indentation in the profiling report or in the source program? In the profiling report. > The report prints some function names not from the beginning of the > line ... > Maybe, you can give a simple example of a program with SCC when the > center is printed twice? For I do not understand this point. eg. f x = x * 2 g x = f x main = print (f 3 + g 3) here f is called both from main and from g, and will appear twice in the profile. > Now I replaced SCC with -auto-all, and it gives a report which > looks satisfactory. > The first part > lpo TermComp 29.9 47.0 > relates Prelude1 13.1 1.5 > ... > is helpful all right. > But I also need to know how many times there was called a certain > function f, no matter from where it is called and whether it > occurs in the first part of the report. I search for `f' in > the large second part of the report. And find the two (often many) > lines (with different indentation): > > f Module1 10 20 ... > ... > f Module1 121 30 ... > > So, `f' was entered 20 times from one point and 30 times from another, > and 50 times in total. Right? Yes. Simon

1 0

profiling usage
by Serge D. Mechveliani 26 Jan '05

26 Jan '05

Dear GHC experts, I have another question about the profiling usage in ghc-6.2.2. I thank "Simon Marlow" <simonmar(a)microsoft.com> for the explanations. We wrote >> There was set a single point of {-# SCC "isReducibleAtTop" #-}. >> Why the report prints the two different lines for it? > You removed the indentation, which was there to indicate the call > nesting. A cost centre that appears more than once indicates that it > was called in two places in your program (or called with two different > lexical call stacks, to be precise). The indentation in the profiling report or in the source program? The report prints some function names not from the beginning of the line ... Maybe, you can give a simple example of a program with SCC when the center is printed twice? For I do not understand this point. Now I replaced SCC with -auto-all, and it gives a report which looks satisfactory. The first part lpo TermComp 29.9 47.0 relates Prelude1 13.1 1.5 ... is helpful all right. But I also need to know how many times there was called a certain function f, no matter from where it is called and whether it occurs in the first part of the report. I search for `f' in the large second part of the report. And find the two (often many) lines (with different indentation): f Module1 10 20 ... ... f Module1 121 30 ... So, `f' was entered 20 times from one point and 30 times from another, and 50 times in total. Right? Thank you in advance for the explanation. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: [ ghc-Feature Requests-1104381 ] Add wxHaskell link to homepage
by Simon Marlow 25 Jan '05

25 Jan '05

They're already tagged with [ ghc-Feature ..... ]. Is that ok? Cheers, Simon ________________________________ From: Seth Kurtzberg [mailto:seth@cql.com] Sent: 24 January 2005 23:45 To: Simon Marlow Cc: Ketil Malde; glasgow-haskell-users(a)haskell.org Subject: Re: [ ghc-Feature Requests-1104381 ] Add wxHaskell link to homepage I would prefer to keep them on the list. There are already a number of different lists, and (of course IMO) I can't see a need to read _only_ feature requests, so why separate them? Adding a tag to the email that would let maildrop or procmail deliver it to a different folder would be a nice solution; those who want the current situation would do nothing, and those who would prefer not to see those messages can add a simple rule to maildrop. (I hesitate to use "procmail" and "simple" in the same sentence, but it presumably wouldn't be terribly difficult there either.) Simon Marlow wrote: On 18 January 2005 14:42, Ketil Malde wrote: I seem to be getting messages from Sourceforge from this mailing list. Is that an intended use for ghc-users? It's intentional, but it can be easily turned off. Do people want to see feature-requests, task-list entries and so forth on this mailing list, or should they be confined to, say, cvs-ghc(a)haskell.org? Cheers, Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users !DSPAM:41f13d8a187771680466285!

1 0

RE: profiling usage
by Simon Marlow 25 Jan '05

25 Jan '05

On 24 January 2005 09:11, Serge D. Mechveliani wrote: > --------------------------------------------------------------------- > Mon Jan 24 10:30 2005 Time and Allocation Profiling Report (Final) > > a.out +RTS -M40m -p -RTS > > total time = 9.04 secs (452 ticks @ 20 ms) > total alloc = 1,047,303,220 bytes (excludes profiling overheads) > > COST CENTRE MODULE %time %alloc > > nubCommut Prelude5 90.0 88.8 > isReducibleAtTop Reduce 9.1 9.8 > > individual inherited > COST CENTRE MODULE no. entries %time %alloc %time %alloc > > MAIN MAIN 1 0 0.0 0.0 100.0 100.0 > CAF Main 242 3 0.0 0.0 0.0 0.0 > ... > ... > operatorOccurs Prelude3 250 19526 0.0 0.2 0.0 0.2 > concat in nextTermLevel Prelude5 249 183 0.0 0.2 98.7 98.1 > isReducibleAtTop Reduce 257 4525 8.4 9.0 8.4 9.0 > orderIfCommut Prelude5 256 7052 0.2 0.1 0.2 0.1 > nubCommut Prelude5 255 4582 90.0 88.8 90.0 88.8 > vectorsOfDepthOfSorts Prelude5 251 379 0.0 0.0 0.0 0.0 > vectorsUnderDepthOfSorts Prelude5 254 260 0.0 0.0 0.0 0.0 > isReducibleAtTop Reduce 248 314 0.6 0.8 0.6 0.8 > ------------------------------------------------------------------------ - > > 1. There was set a single point of {-# SCC "isReducibleAtTop" #-}. > Why the report prints the two different lines for it? > What is the meaning of such duplication? You removed the indentation, which was there to indicate the call nesting. A cost centre that appears more than once indicates that it was called in two places in your program (or called with two different lexical call stacks, to be precise). > 2. It prints six number columns instead of 5 explained in the > User Guide 5.00 (I am looking into now). > The second column looks new. What does it mean? The first column is the new one. It is just an integer identifier for each cost centre stack. I can't remember why we added it to the profile (probably something to do with relating this output to heap profiles). > 3. Consider the line > "concat in nextTermLevel" Prelude5 249 183 0.0 0.2 98.7 98.1 > > This center was set in the following style: > ... > Just class_s -> {-# SCC "concat in nextTermLevel" #-} > concat > [ofTop f | f <- ops, coarity f == s .. ] > where > ofTop f = ... > ... > nubCommut (t:ts) = {-# SCC "nubCommut" #-} ... > > Now, the line meaning is as follows. > (a) This center was entered 249 times. > (b) What does this mean 183 ? entered 183 times, I think. > (c) This very point itself takes almost zero time. > (d) The computation tree below this point (caused by this call) > takes 98.7% of the total time. > Right? Yes > The `nubCommut' call is the part of the tree below > "concat in nextTermLevel". And its line shows that it takes 90% > by itself. > So, the main expense is by nubCommut, and the rest of > "concat in nextTermLevel" adds about 9% to it. These 9% include, > in particular, the cost of the (++) calls. > Right? Yes, I think so (but you removed the indentation, so I can't tell for sure). Cheers, Simon

1 0

RE: Problem with handles in GHC from CVS
by Simon Marlow 25 Jan '05

25 Jan '05

On 24 January 2005 04:31, Wolfgang Thaller wrote: >> It seems they should always be flushed. certainly if a program fails >> via 'fail' in IO or 'error' as these are common ways for programs to >> report an error and losing output would definitly be counter >> intuitive and make it quite tricky to debug. especially when you >> can't flush stdout before calling error. I would think it should >> flush all buffers on any type of exit. > > I agree (after thinking about it again). Done. They were supposed to be flushed always; it was a braino on my part. Thanks for fixing it. Cheers, Simon

1 0

GHC on Arm
by John Goerzen 25 Jan '05

25 Jan '05

Hello, I would like to port GHC to Arm so that I can compile Haskell programs for use on my Zaurus or in Debian's ARM port. I have talked to Ian Lynagh about this, and he believes that there was some sort of problems with floats. I don't know exactly that was, if it was in gcc or ghc, or if it has been fixed. Does anybody have some light to shed on this? Also, does anybody have any ARM binaries of ghc to ease the bootstrapping pain? Thanks!

2 2

RE: [ ghc-Feature Requests-1104381 ] Add wxHaskell link to homepage
by Simon Marlow 24 Jan '05

24 Jan '05

On 18 January 2005 14:42, Ketil Malde wrote: > I seem to be getting messages from Sourceforge from this mailing > list. Is that an intended use for ghc-users? It's intentional, but it can be easily turned off. Do people want to see feature-requests, task-list entries and so forth on this mailing list, or should they be confined to, say, cvs-ghc(a)haskell.org? Cheers, Simon

3 2

Re:'ghc --version' problem
by Alson Kemp 24 Jan '05

24 Jan '05

># ghc-6.3.3 --version > conftest ># cat conftest > [conftest is empty] Just updated my source and this works now. This was a dup of Krasimir's problem anyway. - Alson

1 0

'ghc --version' problem
by Alson Kemp 24 Jan '05

24 Jan '05

I was just trying to compile a package using ghc-6.3.3 and came up against a problem with the '--version'flag. Specifically, I don't think that 'ghc-6.3.3 --version' doesn't report the version to stdout. # ghc-6.3.3 --version > conftest # cat conftest [conftest is empty] #ghc-6.2 --version > conftest # cat conftest The Glorious Glasgow Haskell Compilation System, version 6.2.2 I've looked through ghc/compiler/main/DriverFlags.hs, but both older and newer versions seem to report --version through stdout, so I'm not sure where the problem is. - Alson

1 0

adventure with profiling
by Serge D. Mechveliani 24 Jan '05

24 Jan '05

The pro-filing has proved its power once more. My complex program has a fragment which generates many arithmetical expressions, filtering out `reducible' ones and nub-bing them with respect to the commutativity of some operators. I expected the `reducible' test to take most of the cost. But the whole program has taken suspiciousely long. The profiling showed that nub_by_commutatitvity (nub) takes 10 times more than the `reducible' test. It was hard to discover this without profiling, because the program has many places to suspect. Then, I tried for this fragment (setToList . mkSet) instead of nub ! The whole test has become faster 8 times! `nub-like' reduced to 0.01; the `reducible' test takes 3/4, as it was initially expected. Quite an adventure. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0