[m-rev.] Proposing a new grade for profiling of the parallel runtime system.

[Paul Bone]

On Fri, Dec 04, 2009 at 10:13:35AM +1100, Zoltan Somogyi wrote:
> 
> You will have to shout VERY LOUDLY :-(

Even if I could doing so would cause tidal waves and other havoc. :-)

> For now, and until this stuff has been fully debugged and we have reasonable
> confidence in its correctness (grounded in experience, not hope), I think
> we don't need a new grade for it, at least not committed in the repository.

Why should it not be committed?  If it's a separate grade it will have less of
an effect on the rest of the system.  I can probably create a git branch like
Peter Wang does, and work on it there.

> > Maybe it should be called par_prof and one can have
> > asm_fast.gc.par and asm_fast.gc.par_prof.
> 
> I think we should use a more specific name than "prof" for this, but yes,
> if we have a new grade component, that's roughly what it would look like.
> 
> > Mostly I want to discuss the pros
> > and cons of this
> 
> I am sure you can have a heated discussion with the other inhabitants
> of the Mercury room about this, in which they would raise pretty much every
> point I would.

It's just Mark and I here today, but I'll ask.  Anyone else may feel free to
weigh in via e-mail.  Also, we have telephones, but we can't call long distance
from the office.

Peter Wang, do you want to come over at about 2pm and drink coffee with us?  We
can discuss any pros and cons then.

The points that Mark and I can think about now are:

  Pro: Because threadscope and parallel-profiling support will always incur a
       runtime cost, even when it's disabled at runtime.  Therefore, we won't
       want to have it compiled into the normal asm_fast.gc.par grade.
       Creating a separate grade rather than using a C macro makes things
       easier.

  Pro: Because threascope profiling modifies the MercuryEngine structure and
       the MR_Context structure it is binary incompatible with runtimes,
       libraries and programs without this support.  Rather than add these
       fields in all parallel grades a separate grade component for parallel
       runtime profiling makes these structures marginally smaller in the normal
       parallel grades.

  Con: Adding an extra grade component means we have yet another grade (or two)
       to build and test.
  
  Pro: I want to build and test this feature on a few systems anyway - having a
       new grade component makes that easier.

  Con: I'm concerned that users of Mercury will use this possibly immature
       feature, and try to gain insights into their programs' behaviour that
       may not be true.  I think this is more likely if a grade is provided
       with this support.

  Pro: Contrary to the above point, having an extra grade component makes it
       easier for others to verify my work.

  Con: Creating an extra grade involves work.

  Con: I want to avoid confusing people, and avoid making 'mmake install' take
       longer.

Having had to think about these points while I listed them.  I've decided that
I definitely want a new grade component.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 489 bytes
Desc: Digital signature
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20091204/7a294fad/attachment.sig>