Profiling bugs in 6.8.1 and 6.6.1

[Simon Marlow]

Daniel Fischer wrote:
> Hello,
> 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 
> secs:
> 
> 	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 
reproduce?

> Could that be caused by commenting out the lines
> ifeq "$(GhcThreaded)" "YES"
> SRC_HC_OPTS += -threaded
> endif
> 
> 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 
> enough.

Yes, please send us the code - better still, open a ticket on the bug tracker.

Cheers,
	Simon