[m-rev.] diff: add library routines for controlling profiling

[Ian MacLarty]

On Wed, Sep 27, 2006 at 06:27:19PM +1000, Julien Fischer wrote:
> 
> On Wed, 27 Sep 2006, Ian MacLarty wrote:
> 
> >On Wed, Sep 27, 2006 at 05:28:22PM +1000, Julien Fischer wrote:
> >>
> >>On Wed, 27 Sep 2006, Ian MacLarty wrote:
> >>
> >>>On Wed, Sep 27, 2006 at 08:19:41AM +0200, Peter Ross wrote:
> >>>>Hi,
> >>>>
> >>>>
> >>>>===================================================================
> >>>>
> >>>>
> >>>>Estimated hours taken: 1
> >>>>Branches: main
> >>>>
> >>>>library/benchmarking.m:
> >>>>	Programmatically turn profiling on and off.
> >>>>
> >>>>
> >>>>Index: library/benchmarking.m
> >>>>===================================================================
> >>>...
> >>>>+
> >>>>+:- pragma foreign_decl(c, local, "
> >>>>+#include ""mercury_prof.h""
> >>>>+#include ""mercury_heap_profile.h""
> >>>>+").
> >>>>+
> >>>>+:- pragma foreign_proc(c, turn_off_call_profiling,
> >>>>+        [will_not_call_mercury, thread_safe, tabled_for_io], "
> >>>
> >>>tabled_for_io doesn't have any effect if there are no io state arguments
> >>>(even if the proc is impure).  I'm not sure you want to table these
> >>>anyway, since I wouldn't imagine anyone would want to debug and profile
> >>>their program at the same time.
> >>
> >>Yes, but the calls to them might still be in a program that is being
> >>debugged.
> >>
> >
> >But such calls would be no-ops, so tabling would be unnecessary.
> 
> They're foreign code; how is the Mercury compiler to know that they
> are no-ops?
> 
> >Anyway consider if these were tabled and you were debugging and
> >profiling the program at the same time.  Suppose profiling were turned off 
> >at
> >program start and then turned on half way through a long computation.
> >Then suppose you perform a retry to somewhere before the profiling is
> >turned on.  Now on re-execution you'll get profiling of parts of the
> >program where profiling should be been turned off and double-profiling of 
> >other
> >parts.  Of course disabling tabling won't change this, but it seems
> >silly to have a tabled_for_io there when that's not going to do anything
> >useful.
> 
> It's not silly to have it there if it stops the debugger complaining
> about unsafe retries - which is presumably why you would put it there.
> 

Okay, good point, however you won't get a warning anyway at the moment
since the code is impure.

I still think the impure versions shouldn't be there at all, since this
sort of thing is exactly what trace goals are for and doing it with
impure code is the wrong solution since it either requires you to make
all the ancestor calls that don't take the io state impure or to lie to
the compiler.

Ian.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------