Profiling bugs in 6.8.1 and 6.6.1
simonmarhaskell at gmail.com
Mon Nov 26 04:33:21 EST 2007
Daniel Fischer wrote:
> first let me remark that 6.8.1 is really remarkable, compiles faster and
> produces faster executables than 6.6.1.
> However, I have a problem with profiling, the time is always reported as 0.00
> Sun Nov 25 22:58 2007 Time and Allocation Profiling Report (Final)
> p28Master +RTS -P -hb -sstderr -RTS MMDataA
> total time = 0.00 secs (0 ticks @ 20 ms)
> total alloc = 1,313,421,840 bytes (excludes profiling overheads)
> although it took more than 15 seconds:
> INIT time 0.00s ( 0.00s elapsed)
> MUT time 16.10s ( 16.41s elapsed)
> GC time 10.76s ( 11.16s elapsed)
> RP time 0.00s ( 0.00s elapsed)
> PROF time 0.00s ( 0.00s elapsed)
> EXIT time 0.00s ( 0.00s elapsed)
> Total time 26.86s ( 27.57s elapsed)
Very strange, looks like a bug. Can you provide us with code and steps to
> Could that be caused by commenting out the lines
> ifeq "$(GhcThreaded)" "YES"
> SRC_HC_OPTS += -threaded
> in compiler/Makefile.ghcbin ?
I doubt it - that affects the runtime that GHC itself is linked with, and
shouldn't affect any programs built using that GHC.
> I did that because if I build ghc with -threaded, the times reported with
> :set +s
> in ghci are rubbish (I have a linux 2.4.20 kernel, and the threads don't
> support process-wide times; and no, I'm not likely to upgrade, SuSE 8.2 is
> the only OS that ever worked properly for me).
Fair enough, but note that without -threaded you won't be able to run code
that expects -threaded in GHCi (sounds obvious, I know!). For example,
calling waitForProcess will block all threads.
> If that's the cause, too bad, I'll have to revert to 6.4.2 for profiling :(
> In 6.6.1, -O2 and -prof -auto-all don't work together well, I have a programme
> where that combination of options results in an instant wrong output, while
> the combinations
> -prof -auto-all
> -O1 -prof -auto-all
> -O2 -prof
> lead to the correct output calculated in 10 to 13 seconds.
> If you're interested in that bug, I could send you the code, it's short
Yes, please send us the code - better still, open a ticket on the bug tracker.
More information about the Glasgow-haskell-users