Re: profiling mutator time per function vs. GC time
Simon Marlow wrote: > If you run a profiled program with +RTS -sstderr, the time breakdown > includes an extra category, PROF, which counts the time spent in the > heap profiler. The amount of GC time consumed by the profiled program > will indeed be different from the unprofiled program, because of > profiling overheads - there's no way around this, I'm afraid. But you > may find that the ratio of mutator to GC time in the profiled program is > similar to the unprofiled program (I'd be interested to know whether > this is/is not the case). It seems I stumbled on a situation where this is not the case. The following is a simplified version of my program: > module Main where > > f xs = fst (go xs (id,id)) [] >where go (x:xs) ys = go xs ((\(rw,rl) -> (\zs->x:rl zs,\zs->rw (x:zs))) ys) > go [] ys = ys > > main = do print (let r = (map f (replicate 3000 (replicate 3000 0))) > in r==r) Without profiling support, I get: ~> ghc-5.04.1 -O ratioGC.lhs ~> ./a.out +RTS -sstderr ... INIT time0.00s ( 0.00s elapsed) MUT time8.18s ( 8.20s elapsed) GCtime2.84s ( 3.13s elapsed) EXIT time0.00s ( 0.00s elapsed) Total time 11.02s ( 11.33s elapsed) ... When compiled for profiling, I get: ~> ghc-5.04.1 -O ratioGC.lhs -prof -auto-all ~> ./a.out +RTS -sstderr ... INIT time0.01s ( 0.01s elapsed) MUT time 19.94s ( 21.38s elapsed) GCtime 17.96s ( 19.70s elapsed) RPtime0.00s ( 0.00s elapsed) PROF time0.00s ( 0.00s elapsed) EXIT time0.00s ( 0.00s elapsed) Total time 37.91s ( 41.09s elapsed) ... So, the MUT vs. GC time ratio varies much with the program compiled for profiling support. My actual aim is to compare different implementations of f with respect to both runtime for expression evaluation, and induced amount of GC. To measure really just the runtime for f (in contrast to the test frame with generation of test data and consumption via the forced (==)-check), I wanted to use cost centre profiling, but the big change in GC behaviour forbids this. Adding the GC time from the first run (without profiling) and the mutator time for cost centre f from a profiled run is also not an option, because the time attributed to f by the profiler is bigger than the overall runtime of the unprofiled program, so the scale differs completely. I guess I will settle for more accurate total runtimes (including GC time) without cost centre profiling, and hence without seperation of algorithm from test infrastructure. Regards, Janis. -- Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@;tcs.inf.tu-dresden.de ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCi on Mac OS X
I know that I must install the readline library seperately; can anybody tell me how to do this? It may be that you have the wrong version of the readline library installed. Probably no version at all... Go to http://www.gnu.org/order/ftp.html choose a mirror, download the sources for version 4.3. Unpack it, and use the usual commands for building & installing GNU software: ./configure make sudo make install If there are any problems, e-mail me (auf Deutsch). Cheers, Wolfgang Thaller ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHCi on Mac OS X
> When I start the ghci with -package data, I get the following output: > > Loading package base ... linking ... done. > Loading package haskell98 ... linking ... done. > Loading package lang ... linking ... done. > Loading package concurrent ... linking ... done. > Loading package posix ... linking ... done. > Loading package util ... linking ... not found: _rl_funmap_names > Abort > > I know that I must install the readline library seperately; > can anybody tell me how to do this? It may be that you have the wrong version of the readline library installed. We're chasing a similar problem on SuSE Linux, but I haven't managed to trace the cause yet. Sorry I can't be any more help... Wolfgang - any ideas? Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: profiling mutator time per function vs. GC time
> It seems I have two options: > > A) compile without profiling support and run the compiled > program with +RTS -sstderr > > B) compile with profiling support -prof -auto-all and run > the compiled program with +RTS -p -sstderr > > In case A, I get a good measure of GC vs. mutator time, but I > don't know > the amount of time used by single functions, so I can't > seperate between > mutator time spent in the functions that really interest me > and the time > spent for the test frame. > > In case B, I can seperate mutator time spent in single > functions, but I > have the impression that the GC time I then get includes the > GC for the > profiler, and hence is useless for me, because different GC times for > different algorithms might just mean that one of the > algorithms requires more profiling overhead. If you run a profiled program with +RTS -sstderr, the time breakdown includes an extra category, PROF, which counts the time spent in the heap profiler. The amount of GC time consumed by the profiled program will indeed be different from the unprofiled program, because of profiling overheads - there's no way around this, I'm afraid. But you may find that the ratio of mutator to GC time in the profiled program is similar to the unprofiled program (I'd be interested to know whether this is/is not the case). To get the most reliable measure of GC time in a profiled program, do not turn on heap profiling, because this will cause extra GCs to be performed and will inflate the GC time. Turing on time profiling should be ok. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Nightly build snapshots available
> At 2002-11-07 06:10, Ralf Hinze wrote: > > >I would appreciate a little note saying "this snapshot is ok", > >or "this one is horribly broken", or maybe "this one is a milestone", > >if this is at all possible. > > Heh, I suspect that's for us to find out... Well, most of the time you know as much as me :-) I don't want to tag each snapshot with a personal certification of stability because (a) most of the time I have no idea, (b) it's extra work (I went to a lot of trouble to automate all this), (c) there are likely to be cases exercised by your code but not by any of our tests, and (d) the nightly build logs contain a nice testing report stating which tests failed for each snapshot. Currently, for example, we're running at about 7 test case failures out of 3000-ish, and these failures are mostly harmless (floating-point differences when programs are compiled with the native code generator). The compiler is relatively stable at the moment, but your mileage may vary... (PS sorry about the lack of a source dist from last night's build again, hopefully it'll appear tonight). Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
profiling mutator time per function vs. GC time
Hello, I want to profile a program, to find out: a) the time spent in expression evaluation per function (mutator time) b) the amount of garbage collection caused by the whole program It seems I have two options: A) compile without profiling support and run the compiled program with +RTS -sstderr B) compile with profiling support -prof -auto-all and run the compiled program with +RTS -p -sstderr In case A, I get a good measure of GC vs. mutator time, but I don't know the amount of time used by single functions, so I can't seperate between mutator time spent in the functions that really interest me and the time spent for the test frame. In case B, I can seperate mutator time spent in single functions, but I have the impression that the GC time I then get includes the GC for the profiler, and hence is useless for me, because different GC times for different algorithms might just mean that one of the algorithms requires more profiling overhead. Is this impression correct? If so, then it seems I can't obtain all the information about my program that I want, except there is an option C, of which I don't know? Any hints welcome, Janis. -- Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@;tcs.inf.tu-dresden.de ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
