parallel cost-centre profiling
marlowsd at gmail.com
Thu Jul 1 05:27:23 EDT 2010
On 23/06/2010 18:44, Henrique Ferreiro wrote:
> 2010/6/15 Simon Marlow<marlowsd at 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.
More information about the Cvs-ghc