A Summary of LP Profilers

Appeared in Volume 6/4, November 1993

ducasse@irisa.fr
Mireille Ducasse
28th June 1993

I wrote:
I am interested to know which Prolog (or LP) systems have a profiler. For those which have a profiler, is it based on:

• counting invocations

• measuring cpu and elapsed time

• other ?

Joachim Schimpf
joachim@ecrc.de

ECLiPSe has a profiling tool similar to Unix prof(1): The execution of the program is sampled in regular time intervals and afterwards a table is produced which shows how much time was spent in the different predicates. This profiler does not require any special compilation of the program, it works on the fully optimized code. Sample output:

Predicate    Module   %Time   Time
partition/4  eclipse   62.7%   1.77s
qsort/3      eclipse    3.8%   0.11s
...

Procedure#   Module  #Call #Exit #Try  #Cut #Nrxt  #Fail
partition/4  eclipse  275   275   225   103   122   0
qsort/3      eclipse  101   101     0     0     0   0
...

The SWI-Prolog profiler summarises:

• CPU time spent 'in the box' of a predicate. It can optionally add the cpu-time of decendants, but this is a bit shaky as it does not cooperate very well with optimized code.

• Counts on all 4 ports.

Predicate   Box Entries=  Calls+Redos=   Exits+Fails    Time
country/10   3,905=        3,284+621=     2,712+1,193   8.9%
contains0/2  3,572=        2,157+1,415=   1,960+1,612   7.9%

Two profilers are available in Prolog/Mali (available at ftp://ftp.irisa.fr).

The first profiler works with the special code generated for the debugger. The profiler gives the time passed in each goal (referenced by the filename and the line number). The information is only relevant for "long" goals. For example in a compiler you get easily gather information about the time for parsing, type-checking, and the code generation phases.

The second tool works with the two compilation modes (normal and "debug"). It uses the same ideas as the ECLiPSe profiler.

In "normal" mode, the time for each predicate is provided.

In "debug" mode, the time for each predicate and percentage for each goal (referenced by the filename and the line number) calling this predicate are provided.

The two profilers have been successfully used to improve the system.

Takashi Chikayama
chik@icot.or.jp

Parallel implementations of the concurrent logic programming language KL1 on PIM (Parallel Inference Machine) systems have profilers with common interfaces. There are two versions of them, one for program level profiling and another for physical processor level profiling.

The primitive functions are built into the language implementation. Using these primitives, a graphical profiler is written in KL1 itself (with an X-window interface written in C), as part of the software development environment provided by the PIMOS operating system.

The program level profiler can provide:

• Counting of invocations, suspensions, reductions with processor number

• By periodically gathering the information, a graphical display of the execution profile can be obtained with three axes: What, When and Where. You can choose one of the three different 2-D display formats: What x When, What x Where and When x Where.

The processor level profiler can provide:

• Work rates of the processors. To be precise, it can divide elapsed time into one of: computation, communication, garbage collection and idling. These are given for each processor.

• Numbers of communication messages sent and received by each processor.

• Again, you can periodically sample these values for a real-time graphic profiler with three different display formats.

They are reported in the following article:

S Aikawa, M Kamiko, H Kubo, F Matsuzawa and T Chikayama, ParaGraph: A Graphical Tuning Tool for Multiprocessor Systems, Proc. of FGCS'92, ICOT, Tokyo, Japan, pp.286-293, 1992

One thing to note: the largest PIM system has 512 processors. Even when the graphical display uses only one CRT raster line for each processor, the window already has 512 dots. You have to design the display format very carefully to convey the profiling information to the users in an understandable form.

Manuel Carro
mcarro@fi.upm.es

The gauge profiler comes with SICStus 2.1. SICStus WAM code can be produced that gathers information about number of calls, execution time, choice points created, shallow and deep failures and backtracking (number of times a procedure is entered by backtracking). These can work at the predicate and clause level, taking into account user+system clauses. There is also a nice graphical interface.

The parallel system &-Prolog [1] also has a graphical visualizing tool, VisAndOr [2], aimed at understanding and debugging parallel programs written in Prolog. VisAndOr was mainly developed by Luis Gomez and can currently visualize Independent And-parallelism, Or-parallelism and Dependent Determinate And-parallelism.

[1] M. Hermenegildo and K. Greene, &-Prolog and its Performance: Exploiting Independent And-Parallelism, New Generation Computing, Volume 9, Numbers 3,4, Springer Verlag 1991

[2] M. Carro and L. Gomez and M. Hermenegildo, Some Paradigms for Visualizing Parallel Execution of Logic Programs, Proc. of ICLP 93, MIT Press 1993

Daniel Cohen
dc@dcs.qmw.ac.uk

There is a profiler for STRAND88, written by Carl Kesselman of The Aerospace Corporation. It counts invocations of both Strand procedures and kernels, plus suspensions, breakdowns of where procedures were called from, and cpu time for the kernels. STRAND88 is parallel so it also measures processor utilisation for each processor, plus idle times and message counts/volumes.

The profiler doesn't take a very declarative, or LP-based view, of execution.

Ted Walker
ted@expert.demon.co.uk

All PC versions of Expert Systems Ltd. Prolog-2 are avaialble with PTANG, a cpu based timing system for predicates.

Andrew Verden
andrew@ifc6000.ifcomputer.de

IF/Prolog version 4.2 contains several facilities for profiling.

• an invokation counting meta-interpreter for general analysis

• cpu timing from within the debugger (as one 'leaps' over goals)

I think the main problem is that getting timings is a bit problematic in Unix. Their method gets around that by making some statistical assumptions. It would be nice to be able to get accurate timings under Unix but I don't think any machine offers this capability.

Norbert E. Fuchs
fuchs@ifi.unizh.ch

We are using a simple profiler counting invocations that is based on a profiler published by Chikayama some time ago on the net. We are in the process of integrating the profiler into the MacProlog interface.

We also have a separate profiler measuring elapsed time that we integrated into MacProlog.

Mireille Ducasse
mireille@ecrc.de

Some useful papers:

E. Tick, Visualizing Parallel Logic Programs with VISTA, Proc. of the Int. Conf. on Fifth Generation Computer Systems, 1992, pp.934-942, ICOT, June

M.M. Gorlick and C.F. Kesselman, Timing Prolog programs without clocks, Symp. on LP, 1987, pp.426-432, IEEE Computer Society

J. Cohen and N. Carpenter, A language for inquiring about the run-time behaviour of programs, Software-Practice and Experience, 1977, Vol.7, pp.445-460

Jacques Noye
jacques@ecrc.de

Some useful papers:

C. Svensson and J. Sundberg, MUSE trace. A graphic tracer for Or-parallel Prolog, SICS, 1990, Technical Report, T90003)

D.C. Sehr and L.V. Kalé, Estimating the Inherent Parallelism in Prolog Programs, Proc. FGCS'92, Japan, July, 1992, pp.783-790

M.J. Fernández and M. Carro and M. Hermenegildo, IDeal Resource Allocation (IDRA): A Technique for Computing Accurate Ideal Speedups in Parallel Logic Langauges, Computer Science Faculty, Technical University of Madrid, 1992, Technical Report, FIM26.3/AI/92, September