On 23/06/2010 18:44, Henrique Ferreiro wrote:
2010/6/15 Simon Marlow<marlo...@gmail.com>:
On 15/06/2010 16:28, Henrique Ferreiro wrote:
I got the most important pieces working (I think). The question now
is, are you interested in this?
It all depends on whether other people would find it useful or not. At the
moment I'm not convinced that profiling each Capability separately will give
results that are useful, because the assignment of work to Capabilities is
quite arbitrary and will change from run to run. The only way to get
meaningful results would be to use forkOnIO; this won't be very useful for
par/pseq or Strategies.
I've been thinking about this and came to the conclusion that
profiling per capability isn't only useless but wrong as it might
build stacks of completely unrelated code.
You said before that per-thread profiling is much harder. So, what
would be the problem of saving and restoring the profiling information
each time a thread is run?
So one option is to make a new CCS root for each thread, and that way
each thread would end up creating its own tree of CCSs. That would seem
to work nicely - you get per-thread stacks almost for free.
Unfortunately it's not really per-thread profiling, because if one
thread happens to evaluate a thunk created by another thread then the
costs of doing so would be attributed to the thread that created the
thunk (maybe that's what you want, and maybe it's consistent with the
CCS view of the world, I'm not sure). This also means you still need to
lock access to the CCS structures, because two threads might be
accessing the same one simultaneously.
Do you really want per-thread profiling, anyway? What happens when
there are thousands of threads?
I didn't know about this. I've done some really small tests and the
overhead of the HPC system seems lower the the one from the profiling
system. The problem I see is that it may have to be changed a lot to
comply with the cost centre semantics (subsuming costs and the like).
Well, it would be a completely different cost semantics. Whether that's
good or bad I can't say.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
