[m-dev.] detail profiling

[Erwan Jahier]

Zoltan wrote:

| I am in the process of implementing a detail profiler, which is analogous
| to basic block profilers for imperative languages. It inserts counters into
| the generated code in several places: at entries to procedures, at entries
| to switch arms, disjunction arms, then parts and else parts, and at the exits
| from primitive (non-compound) goals whose determinism is not det, cc_multi,
| erroneous or failure. (For goals with those determinisms, the number of times
| the program point after the goal is reached is uniquely determined by the
| determinism and by the number of times the program point before the goal
| is reached; this is not true for other determinisms.)
|
| I selected those sites, because this is a set of sites that is close to
| minimal, yet allows a reasonably simple tool to compute the number of times
| each program point is reached.

Don't you feel like the impression you are re-implementing (a subset of) the
tracer here?

				-o-

| For performance engineering, the tool should order the procedure in profiled
| modules, ordered on
| 
| - the number of times the procedure is called
| 
| - the number of times the most frequently reached program point
|   in the procedure was executed
| 
| - the bisection width of the procedure, which is computed as follows:
| 
|   - for a sequence of conjoined goals, the bisection width is the
|     maximum number of times any program point in the sequence is reached
| 
|   - for a set of disjoined goals, the bisection width is the
|     sum of the bisection widths of the alternatives

The order in which you want to display those results certainly depends on the
application you analyze, on the user's mood and on what the user want to see.
Hence a need for a flexible tool that lets users specify exactly what they
need (see my previous post).

				-o-

| I am seeking feedback on two points.
| 
| - Are the alternative outputs I propose sufficient? Are there others I left
|   out that would be sufficiently useful to justify their implementation cost?

This is certainly a difficult question to answer; that is another argument for
a flexible tool ;-)


| - What form should the output take? One possibility is to just list names
|   and then the definitions of the top N procedures (or all procedures with
|   non-executed parts for coverage analysis) in plan ASCII. Another is to
|   generate a list of procedure names in HTML, with each name being a link
|   to the corresponding definition in a HTML file of definitions. However,
|   other, better possibilities probably exist.

The `collect' primitive I told you about in my previous post does not rely on
Opium-M. But once `collect' is connected to Opium-M, you've got the full power
of Prolog to analyze/display the results of your monitoring activities; then
users can customize the way they want to output the result (which does not
prevent us to provide default outputs as the one you are just suggesting).


...
I didn't convinced you, eh Zoltan ?-)

-- 
R1.


--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------