Appeared in Volume 6/4, November 1993
28th June 1993
I am interested to know which Prolog (or LP) systems have a profiler. For those which have a profiler, is it based on:
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 ...ECLiPSe also provides a second tool based on its box model debugger. It collects statistics about how often the program execution passed the different box model ports of each predicate. Due to ECLiPSe's extended box model, this information is useful to find unnecessary choicepoints, bad indexing, useless cuts and the like. Sample output:
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 ...Jan Wielemaker
The SWI-Prolog profiler summarises:
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%Pascal Brisset
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.
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:
The processor level profiler can provide:
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.
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  also has a graphical visualizing tool, VisAndOr , 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.
 M. Hermenegildo and K. Greene, &-Prolog and its Performance: Exploiting Independent And-Parallelism, New Generation Computing, Volume 9, Numbers 3,4, Springer Verlag 1991
 M. Carro and L. Gomez and M. Hermenegildo, Some Paradigms for Visualizing Parallel Execution of Logic Programs, Proc. of ICLP 93, MIT Press 1993
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.
All PC versions of Expert Systems Ltd. Prolog-2 are avaialble with PTANG, a cpu based timing system for predicates.
IF/Prolog version 4.2 contains several facilities for profiling.
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
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.
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
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