Prolog performance and recursion type

Question

I was playing with permutation in a couple of programs and stumbled upon this little experiment:

Permutation method 1:

permute([], []).
permute([X|Rest], L) :-
    permute(Rest, L1),
    select(X, L, L1).

Permutation method 2:

permute([], []).
permute(L, [P | P1]) :-
    select(P, L, L1),
    permute(L1, P1).

Permutation method 3 (use the built-in):

permute(L, P) :- permutation(L, P).

I understand that it's good practice to use tail recursion, and generally using built-ins is supposed to be efficient. But when I run the following:

time(findall(P, permute([1,2,3,4,5,6,7,8,9], P), L)).

I got the following results, which are relatively consistent across several runs:

Method 1:

% 772,064 inferences, 1.112 CPU in 2.378 seconds (47% CPU, 694451 Lips)

Method 2:

% 3,322,118 inferences, 2.126 CPU in 4.660 seconds (46% CPU, 1562923 Lips)

Method 3:

% 2,959,245 inferences, 1.967 CPU in 4.217 seconds (47% CPU, 1504539 Lips)

So the non-tail recursive method is quite significantly more real-time efficient.

Is a particular recursion type generally more real time efficient, all other things being equal (I know that's not always a simple premise)? What this experiment tells me is that I may not want to be always striving for tail recursion, but I may need to do a performance analysis first, then weigh performance benefit against other benefits that tail recursion does have.

I haven't seen this question before (I think). I like this topic. if we define `sort(L,S):- permute(L,S), is_ordered(S).` as an executable spec and optimize it to get the actual code, then your first version produces _insertion sort_, and the 2nd -- _selection sort_. We could also split in the middle, permute and combine the halves, I imagine, which would give rise to the _merge sort_ algorithm. — Will Ness, Dec 04 '22 at 09:36

mat · Accepted Answer · 2015-10-30T14:00:42.170

Really nice question, +1!

Tail call (and, as a special case, tail recursion) optimization only applies if the predicate is deterministic! This is not the case here, so your predicate will always require the local stack space, no matter in which order you place the goals. The non-tail recursive version is more (time-)efficient here when generating all solutions because it needs to do fewer unifications on backtracking.

EDIT: I am expanding on this point since it is well worth studying the performance difference in more detail.

First, for clarity, I rename the two different versions to make clear which version I am talking about:

Variant 1: Non-tail recursive:

permute1([], []).
permute1([X|Rest], L) :-
    permute1(Rest, L1),
    select(X, L, L1).

Variant 2: Tail-recursive:

permute2([], []).
permute2(L, [P|P1]) :-
    select(P, L, L1),
    permute2(L1, P1).

Note again that, although the second version is clearly tail recursive, tail call (and hence also tail recursion) optimisation only helps if the predicate is deterministic, and hence cannot help when we generate all permutations, because choice points are still left in that case.

Note also that I am deliberately retaining the original variable naming and main predicate name to avoid introducing more variants. Personally, I prefer a naming convention that makes clear which variables denote lists by appending an s to their names, in analogy to regular English plural. Also, I prefer predicate names that more clearly exhibit the (at least intended and desirable) declarative, relational nature of the code, and recommend to avoid imperative names for this reason.

Consider now unfolding the first variant and partially evaluating it for a list of 3 elements. We start with a simple goal:

?- Xs = [A,B,C], permute1(Xs, L).

and then gradually unfold it by plugging in the definition of permute1/2, while making all head unifications explicit. In the first iteration, we obtain:

?- Xs = [A,B,C], Xs1 = [B,C], permute1(Xs1, L1), select(A, L, L1).

I am marking the head unifications in bold.

Now, still one goal of permute1/2 is left. So we repeat the process, again plugging in the predicate's only applicable rule body in place of its head:

?- Xs = [A,B,C], Xs1 = [B,C], Xs2 = [C], permute1(Xs2, L2), select(B, L1, L2), select(A, L, L1).

One more pass of this, and we obtain:

?- Xs = [A,B,C], Xs1 = [B,C], Xs2 = [C], select(C, L2, []), select(B, L1, L2), select(A, L, L1).

This is what the original goal looks like if we just unfold the definition of permute1/2 repeatedly.

Now, what about the second variant? Again, we start with a simple goal:

?- Xs = [A,B,C], permute2(Xs, Ys).

One iteration of unfolding permute2/2 yields the equivalent version:

?- Xs = [A,B,C], Ys = [P|P1], select(P, Xs, L1), permute2(L1, P1).

and a second iteration yields:

?- Xs = [A,B,C], Ys = [P|P1], select(P, Xs, L1),  Ys1 = [P1|P2], select(P1, L1, L2), permute2(L2, P2).

I leave the third and last iteration as a simple exercise that I strongly recommend you do.

And from this it is clear what we initially probably hadn't expected: A big difference lies in the head unifications, which the first version performs deterministically right at the start, and the second version performs over and over on backtracking.

This famous example nicely shows that, somewhat contrary to common expectation, tail recursion can be quite slow if the code is not deterministic.

"... because it needs to do fewer unifications on backtracking." That is not accurate. The reason why version 2 is slower is the number of calls to `permute/2`. For each answer of `select` it will call `permute/2` whereas version 1 calls `permute/2` only once prior to calling `select/3` — false, Nov 07 '15 at 10:15
That is true, but how do we find out where the time actually goals? Is it the head unification or the overhead of calling the predicate? — mat, Nov 07 '15 at 10:57
The number of inferences is a quite robust **abstract** measure. To analyze concrete measurements is next-to-impossible. And, actually not worthwhile. In the concrete case, the difference between `findall(L, Goal, Ls)` and `(Goal, false)` is a factor of 5 ... — false, Nov 07 '15 at 11:13

CapelliC · Answer 2 · 2013-06-10T08:30:37.783

4

Really nice question.

Waiting for someone to post a time/space analysis, the only caveat I can offer is that method 1 & 2 don't terminate when first argument is free, while method 3 does.

Anyway, method 1 seems really much more efficient than the builtin. Good to know.

edit: and given that the library implementation merely adjust instantiation of arguments and calls method 1, I'm going to discuss on SWI-Prolog mailing list your method 2 as alternative (or, you prefer to do it yourself, let me know).

more edit: I forgot previously to point out that permutation/3 (let's say, method 2), gives lexicographically ordered solutions, while method 1 doesn't. I think that could be a strong preferential requirement, but should be expressed as an option, given the performance gain that method 1 allows.

?- time(call_nth(permute1([0,1,2,3,4,5,6,7,8,9],P),1000000)).
% 3,112,758 inferences, 3,160 CPU in 3,162 seconds (100% CPU, 984974 Lips)
P = [1, 4, 8, 3, 7, 6, 5, 9, 2|...] .

?- time(call_nth(permute2([0,1,2,3,4,5,6,7,8,9],P),1000000)).
% 10,154,843 inferences, 9,779 CPU in 9,806 seconds (100% CPU, 1038398 Lips)
P = [2, 7, 8, 3, 9, 1, 5, 4, 6|...] .

YAP gives still more gain!

?- time(call_nth(permute1([0,1,2,3,4,5,6,7,8,9],P),1000000)).
% 0.716 CPU in 0.719 seconds ( 99% CPU)
P = [1,4,8,3,7,6,5,9,2,0]

?- time(call_nth(permute2([0,1,2,3,4,5,6,7,8,9],P),1000000)).
% 8.357 CPU in 8.368 seconds ( 99% CPU)
P = [2,7,8,3,9,1,5,4,6,0]

edit: I've posted a comment on SWI-Prolog doc page about this theme.

edited Jun 10 '13 at 08:30

answered Jun 10 '13 at 05:21

CapelliC

59,646
5
47
90

1

I cannot actually remember ever using (all) permutations without needing and relying on lexicographical order. Permutations are traditionally enumerated in lexicographical order, and all libraries providing permutations create them in this order. In this sense it would be a bit strange and very misleading to change the order. – Jun 10 '13 at 09:44
@Boris: You're right, [C++](http://en.cppreference.com/w/cpp/algorithm/next_permutation) for instance call the function next_permutation and just advises about lexicographic order in documentation. But a factor 3 (or more) of speedup could be significant. – CapelliC Jun 10 '13 at 09:56
Looking at the link you provided, it seems it is not "just advice", but in the specification. Anyway, I assume the order is important just because all libraries I checked adhere to it (and so do math textbooks). Is there a use for the ordering or is it just convention? – Jun 10 '13 at 10:08
I guess it's just conventional. Naive use of permutation/2, like solving 'zebra-like' puzzles, surely doesn't care about. – CapelliC Jun 10 '13 at 10:21
I did another little test in GNU Prolog and found that running built-in `permutation( X, [1,2,3] )` caused a stack overflow when I pressed `;` after it presented the first solution. Oops. ;) SWI-Prolog worked, but only gives lexicographical order if the instantiated argument is the first one. – lurker Jun 10 '13 at 11:40

score 4 · Answer 3 · edited May 23 '17 at 12:15

I suspect what triggered this investigation was the discussion about tail-recursive sum/2 using an accumulator versus not. The sum/2 example is very cut-and-dry; one version is doing the arithmetic on the stack, the other is using an accumulator. However, like most things in the real world, the general truth is "it depends." For instance, compare the efficiency of methods 1 and 2 using full instantiation:

?- time(permute([1,2,3,4,5,6,7,8,9], [1,2,3,4,5,6,7,8,9])).
% 18 inferences, 0.000 CPU in 0.000 seconds (66% CPU, 857143 Lips)
true ;
% 86,546 inferences, 0.022 CPU in 0.022 seconds (100% CPU, 3974193 Lips)
false.

?- time(permute([1,2,3,4,5,6,7,8,9], [1,2,3,4,5,6,7,8,9])).
% 18 inferences, 0.000 CPU in 0.000 seconds (62% CPU, 857143 Lips)
true ;
% 47 inferences, 0.000 CPU in 0.000 seconds (79% CPU, 940000 Lips)
false.

Method 1 beats method 2 when you're generating solutions (as in your tests), but method 2 beats method 1 when you're simply checking. Looking at the code it's easy to see why: the first one has to re-permute the whole tail of the list, while the second one just has to try selecting out one item. In this case it may be easy to point to the generating case and say it's more desired. That determination is simply one of the tradeoffs one must keep track of when dealing with Prolog. It's very difficult to make predicates that are all things to all people and always perform great; you must decide which are the "privileged paths" and which are not.

I do vaguely recall someone recently showed an example of appending lists "during the return" and how you could take something that isn't or shouldn't be tail recursive and make it work thanks to unification, but I don't have the link handy. Hopefully whoever brought it up last time (Will?) will show up and share it.

Great question, by the way. Your investigation method is valid, you'll just need to take into account other instantiation patterns as well. Speaking personally, I usually try to worry harder about correctness and generality than performance up-front. If I see immediately how to use an accumulator instead I will, but otherwise I won't do it that way until I run into an actual need for better performance. Tail recursion is just one method for improving performance; frequently there are other things that need to be addressed as badly or worse.

from [docs](http://www.swi-prolog.org/pldoc/doc_for?object=permutation/2): `is_permutation(Xs, Ys) :- msort(Xs, Sorted), msort(Ys, Sorted).` — CapelliC, Jun 10 '13 at 07:38
Thanks Daniel. I took the response on `sums` as face-value good advice, and it was consistent with everything else I've ready (that tail recursion is preferred). Then I encountered my somewhat overly trivial example and I was looking for thoughts on it relative to the pervasive advice that tail recursion is best. Your explanation is quite helpful. — lurker, Jun 10 '13 at 11:30
s(X): Thank you for investigating other uses of `perm(Xs,Ys)` than `ground(Xs),var(Ys)`! The way I see things now, "method 2" is the way to go. And even more so if additional constraints are present. — repeat, Oct 19 '15 at 12:05

score 2 · Answer 4 · answered Dec 02 '22 at 12:06

2

Problem:

?- permute1(L, [a]).
L = [a] ;
<Infinite Loop>

Solution:

permute(Lst, Perm) :-
    % Adding Perm, to prevent infinite loop in: permute(L, [a])
    permute_(Lst, Perm, Perm).

permute_([], [], []).
permute_([H|T], [_|TC], [P|TP]) :-
    permute_(T, TC, L1),
    select(H, [P|TP], L1).

answered Dec 02 '22 at 12:06

brebs

3,462
2
3
12

Why not use a conjunction with a `same_length/2` goal? – repeat Dec 02 '22 at 16:25
1

In general, this duplicated-argument method is more flexible. `same_length/2` is a bad choice if the list is potentially long, and the checks *after* such a length-equivalence check fail quickly. It's an isolated check, and can't be integrated into the rest of the hopefully iterate-over-list-elements-efficiently-once code. For this particular example of `permute`, the list is likely to be extremely short... but it's the principle :-) – brebs Dec 02 '22 at 18:51
@brebs: You are compiling same_length/2 into the definition. That is virtually always possible, but it comes at the price of a less readable program. You could add a fitting block declaration to same_length/2 to keep the program more readable... – false Dec 04 '22 at 08:50

score 1 · Answer 5 · 2020-05-31T16:02:02.123

Nice example. But I would rather use, it doesn't leave a choice point in permute([], []):

permute3([], []). 
permute3([H|T], [P|P1]) :- 
    select(P, [H|T], L1), 
    permute3(L1, P1).

Its tail recursive and like 20% faster than permute2/2, but still not as fast as permute1/2.

?- time((permute2([1,2,3,4,5,6,7,8,9,0],_), fail; true)).
% 29,592,302 inferences, 1.653 CPU in 1.667 seconds (99% CPU, 17896885 Lips)
true.

?- time((permute3([1,2,3,4,5,6,7,8,9,0],_), fail; true)).
% 25,963,501 inferences, 1.470 CPU in 1.480 seconds (99% CPU, 17662390 Lips)
true.

But I am not sure whether the explanation by mat is correct. It could be also the case that permute1/2 does less often perform LCO than permute3/2 does.

Namely of n! results of the sub call permute1/2, only the last redo doesn't leave a choice point. On the other hand in permute3/2 every select/3 call has n results and doesn't

leave a choice point in the last redo. I did a little test, write a period for each LCO:

?- permute1([1,2,3],_), fail; nl.
...
?- permute3([1,2,3],_), fail; nl.
..........

LCO has not an extreme benefit in a fail loop. But the Prolog system doesn't know about it. So I guess thats where unnecessary time is spent, to a larger amount in permute3/2.

score 1 · Answer 6 · answered Dec 02 '22 at 21:23

Solution suggested by this comment.

Using a meta-interpreter to count the number of calls:

mi(G, S) :-
    mi([[G]-G], G, [], S).

mi([], G, S, S).
mi([[]-G|_], G, S, S).
mi([Gs-G|Gss0], G0, S0, S) :-
    step(Gs, G, Gss, Gss0, S0, S1),
    mi(Gss, G0, S1, S).

statistics_(PI, S0, S) :-
    select(PI-C0, S0, S1), !,
    succ(C0, C),
    S = [PI-C|S1].
statistics_(PI, S0, S) :-
    S = [PI-1|S0].

step([], _, Gss, Gss, S, S).
step([G0|Gs0], G, Gss, Gss0, S0, S) :-
    functor(G0, A, N),
    statistics_(A/N, S0, S),
    findall(Gs-G, head_body(G0, Gs, Gs0), Gss, Gss0).


head_body(true, Gs, Gs).
head_body((G0,G1), [G0,G1|Gs], Gs).
head_body(A=A, Gs, Gs).

head_body(select(E0,[E0|Es],Es), Gs, Gs).
head_body(select(E0,[E|Es0],[E|Es]), [select(E0,Es0,Es)|Gs], Gs).

head_body(permute1([],[]), Gs, Gs).
head_body(permute1([X|Rest],L), [permute1(Rest,L1),select(X,L,L1)|Gs], Gs).
% head_body(permute1(L0,L), [L0=[],L=[]|Gs], Gs).
% head_body(permute1(L0,L), [L0=[X|Rest],permute1(Rest,L1),select(X,L,L1)|Gs], Gs).

head_body(permute2([],[]), Gs, Gs).
head_body(permute2(L,[P|P1]), [select(P,L,L1),permute2(L1,P1)|Gs], Gs).
% head_body(permute2(L,P0), [L=[],P0=[]|Gs], Gs).
% head_body(permute2(L,P0), [P0=[P|P1],select(P,L,L1),permute2(L1,P1)|Gs], Gs).

The result is the following:

?- mi((permute1([1,2,3,4,5,6,7,8,9],_),false), S).
   S=[false/0-362880,select/3-409113,permute1/2-10,(',')/2-1].
?- mi((permute2([1,2,3,4,5,6,7,8,9],_),false), S).
   S=[select/3-1972819,false/0-362880,permute2/2-986410,(',')/2-1].

And if head unification is delayed with (=)/2:

?- mi((permute1([1,2,3,4,5,6,7,8,9],_),false), S).
   S=[(=)/2-21,false/0-362880,select/3-409113,permute1/2-10,(',')/2-1].
?- mi((permute2([1,2,3,4,5,6,7,8,9],_),false), S).
   S=[select/3-1972819,(=)/2-2335700,false/0-362880,permute2/2-986410,(',')/2-1].

The predicate permute1/2 does less calls than permute2/2 which explains why permute1/2 is faster than permute2/2.

Prolog performance and recursion type

6 Answers6

Linked