@grossdan Expressed a lot of doubts that Prolog can execute deterministic code as fast as C. On the other hand I am rather optimistic about that, although my own Prolog system is also still far off from that goal.
@grossdan Objected mainly that Prolog code needs to execute non-determinism related instructions. On the other hand from my system I don’t see this a problem. Deterministic code does only move forward in a “call” fashion.
A “redo” is only searched when a call fails. But “determistic” means not to fail, and choice points are ommitted, so deterministically succeeding predicates shouldn’t leave any choice point related trace.
Here is a little comparison, take this deterministic code:
elevator(N,M) :-
elevator(N, 0, M).
elevator(0, N, N) :- !.
elevator(N, X, Y) :-
M is N-1,
H is X+1,
elevator(M, H, Y).
SWI-Prolog already performs very well:
?- time((between(1,10000,_), elevator(10000,_), fail; true)).
% 100,030,001 inferences, 2.969 CPU in 2.972 seconds (100% CPU, 33694316 Lips)
true.
But then I find for ECLiPSe Prolog:
[eclipse 10]: between(1,10000,_), elevator(10000,_), fail; true.
Yes (1.72s cpu)
Where is the bottleneck? I think both have tagged integers and bignums. I rather assume this is not the bottle neck it has to do with code generation.