parallel cost-centre profiling

[Simon Marlow]

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.

Cheers,
	Simon