Profiling doesn't work with SMP execution

The profiling subsystem isn't thread-safe at all, so can't be used with -threaded. I've made GHC 6.6 emit an error and refuse to compile rather than generate a crashing binary.

Later, we should fix this. A Big Giant Lock around the profiling subsystem is probably sufficient - it will introduce a bottleneck with -N2 and greater, but it should be ok with single processor runs.

It must cause problem when someone want to optimise Haskell program.

If a programmer find that program is slow, then he profile and try to optimise it.H e find bottleneck long computing function, and he use thread to fix performance problem (Of course, bottleneck isn't memory efficiency in this case).

But now he can't profile his proram again. forkOS cause error without -threaded option.par can work without -threaded option, but profiler doesn't report correct result.

That's too bad.

And I think this problem affect Data Parallel Haskell developping process.

It seem that Data Parallel Haskell generate ndp package's code when vectorising Parallel Array.

• http://darcs.haskell.org/ghc/compiler/vectorise/VectBuiltIn.hs

But ndp can't build with perf or default build.

• http://www.nabble.com/combination-not-supported:-Threaded-Profiling-when-building-NDP-library-t4472936.html

This cause problem when someone tries to use Data Parallel Haskell.

"Comleted" message isn't in Milestone 2, so I think development is late. But WorkPlan? suggests us that Data Parallel Haskell's ndp system will be release near future.

• DataParallel/WorkPlan

So we'll up against this situation soonly.

Hello, it seems that this bug isn't very clear from the documentation or the GHC web page, can we be honest and update

http://haskell.org/ghc/

where it says "Profiling is supported, both by time/allocation and various kinds of heap profiling."

to say "Profiling is supported, both by time/allocation and various kinds of heap profiling, provided you do not use threads."?

Thank you.

Replying to Frederik:

to say "Profiling is supported, both by time/allocation and various kinds of heap profiling, provided you do not use threads."?

Just wanted to make sure there's no misunderstanding here: you can use threads with profiling just fine, the bug is that you can't use the -threaded option with profiling.

Hello, I was just thinking about that too, is it not common for people to use -threaded? Myself, I ran into this problem when I was trying to debug something that I found I had to compile with -threaded to work properly, but maybe I should have been using forkProcess.

Often there's no reason not to use -threaded (unless you want to profile, of course!). But it's only necessary if you want to (a) use multiple processors or (b) make FFI calls that don't block all threads.

OK, well that sounds like a significant chunk of functionality. I guess the benefit of working on non-commercial software is that you don't have to hide the shortcomings of your product. People who are interested to hear that GHC supports profiling are also likely to be interested to know to what extent it supports profiling. The fact that e.g. SMP is excluded is missing from http://haskell.org/ghc/ and http://haskell.org/ghc/docs/latest/html/users_guide/profiling.html, but that is one of the first questions that users who depend on SMP will want to know the answer to.

I've now enabled -prof -threaded, it turns out that there weren't any major problems preventing their use together, we were just being conservative.

However, it is certainly a lot of work to make profiling work with SMP (+RTS -N2), and I don't think this is a high priority: you can just profile on a single CPU. Profiling parallel performance is another problem altogether (which is certainly on our radar). I've added a note to the profiling section of the user guide to mention that +RTS -N2 is not supported with profiling.