10

In the following, I am only considering pure Prolog programs. This means that I am not talking about side-effects and OS calls that leave the realm of logic to do something that cannot be observed from within Prolog.

There is a well-known abstract measure for the run time cost of a Prolog program: The number of logical inferences. By "abstract", I mean that this measure is independent of any particular Prolog implementation and actual concrete hardware. It is a measure in the sense that it gives us some information about the time it will take to execute a program. We can even specify the performance of Prolog systems to some extent by stating their number of inferences per second (LIPS), and this is so widely used that one can call it a traditional measure of system performance. Traditionally, this number is measured by a particular benchmark, but the general notion of "number of inferences" of course extends to other, more complex Prolog programs too.

However, as far as I understand, this particular (dare I say: concrete) abstract measure does not tell the whole truth in the following important sense:

For any given Prolog goal G, let us denote with t(G) : T→R the actual execution time of G on a given Prolog system on particular hardware, i.e. a function from Herbrand terms to the real numbers. Let us call a measure α : T→R truthful iff t(G) ≈ α(G) for all G, in the sense that the values differ by a factor that is bounded by a constant for all goals G and all "realistic" types of hardware (I must leave this last point slightly underspecified, but I am assuming here for simplicity that the same Prolog implementation performs roughly in the same way on "typical" hardware. I know that this is not actually the case, and the same implementation can exhibit drastically different characteristics on different types of hardware. If so, limit the definition to a subset of hardware types where the implementation runs "roughly" the same.)

As far as I know, the number of logical inferences is in general not a truthful measure of the actual execution time of a Prolog goal, in particular because the time it takes to perform unifications is not measured by it. One can construct cases where the difference between this measure and the actual execution time is no longer bounded by a constant.

Therefore, my question: Is there a truthful abstract measure for the run time of a Prolog goal? If it does not exist in general, please specify a meaningful subset of Prolog programs where such a measure can be defined. For example, by restricting the types of unifications that can occur.

This question is of high practical importance for example when using Prolog to implement smart contracts: In such cases, you want to abstractly measure how long it takes to run a Prolog program, even if your program runs on different machines that need to be in agreement about the time it takes running it, and yet you want to preserve the possibility of future improvements to the concrete implementation technology. Therefore, the measure should only depend on the actually given program, not on any concrete features of the implementation, such as the number of memory cells that are accessed.

mat
  • 39,707
  • 3
  • 42
  • 68
  • 2
    Show me a good abstract measure for addition of integers to start with. I have not seen such. Should contain some ld in it. – false Jul 23 '17 at 20:59
  • 2
    For the purpose of termination-inferences, some measures were developed for cTI, but they over-estimated runtime horribly. – false Jul 23 '17 at 21:00
  • 1
    If I understand this correctly, then why is the mechanism by which the goal is reached limited to just Prolog. I am thinking that if you had a goal which can be solved with a perfect engine for solving that specific problem then what you seek is the minimum number of perfect actions on the engine to reach the goal. The best analogy I can think of is solving the traveling salesman problem. The problem is well defined, the engine is well known, and the measure for any answer is easily compared. Just thinking out loud. :) – Guy Coder Jul 23 '17 at 23:17
  • 1
    After thinking about this more and relating it to neural networks, while a network can have many layers, it is also possible to have one layer and get perfect results by having every possible input connected directly to every possible valid output and the cost is always the same. – Guy Coder Jul 24 '17 at 00:17
  • 1
    Maybe we could measure the WAM rather accurately, and aggregate some statistic from there (the profiler could provide something ready to use ?) – CapelliC Jul 24 '17 at 13:52
  • 1
    Of Interest: [Herbrand Semantics](http://logic.stanford.edu/herbrand/herbrand.html) Is this valid for the question? – Guy Coder Jul 25 '17 at 10:46
  • 1
    I'm not sure that what I tell is quite relevant: http://www.sciencedirect.com/science/article/pii/S0747717103000403#aep-section-id20 I hope it helps – Anton Danilov Jul 31 '17 at 06:25

1 Answers1

2

The problem of complexity measures is seen in full bloom here. But lips are still a useful measurement. You dont get:

LIPS ~ TIME

But you get:

LIPS * DEPTH * COUNT ~ TIME

where the depth is a measure of the term depth at runtime, it influences the time cost of unification, and the count is a measure of the number of clauses, it influences the number of unifications, including failures not leading to inferences.

Its the same abstraction as if you would say addition takes one time step, but in fact we know that the time for adding two bignums depends on the size of the bignums. Here the terms and clauses play the role of the bignums.

Is it useful? Definitively yes! For example if you have two algorithm, and see that for both depth and count is the same, you can go with lips to compare them.

Mostowski Collapse
  • 12,118
  • 3
  • 34
  • 78