Why in the program "Prolog for eight puzzle" user slago uses the command: time(ids) I can't undestand why he uses this command - prolog

?- time(ids). What is the meaning of this command? What is the meaning of time?
I am expecting to undestand in Slago's 8-Puzzle proigram the menaing of command ?- time(ids). during execution

?- time(...). prints this at the end of slago's output:
% 97,719,612 inferences, 40.344 CPU in 40.991 seconds (98% CPU, 2422175 Lips)
It's the runtime of the solution in Prolog logical inferences and CPU use in seconds. Good for quick comparisons to see if changes to the code speed it up or slow it down, and good for posting here to show people roughly how long the code takes to search for a solution.

Related

Is it possible to get elapsed time in microseconds in Swi-Prolog?

Simple question.
I need to calculate how long it takes to execute predicate X. So I wrote this predicate:
chronometrise(X) :-
write('Executing: '), write(X), nl, nl,
statistics(walltime, _), call(X), statistics(walltime, [_,E]),
nl, write('Time: '), write(E), write(' ms.'), nl.
This allows me to get time in milliseconds. But I need microseconds.
Is it possible to calculate this in Swi-Prolog? Or milliseconds is best accuracy?
EDIT: Well, I found a better way: execute predicate 1000 times and calculate elapsed time. This will give us average execution time in milliseconds multiplyed by 1000, which is exactly average elapsed time in microseconds.
Instead of using statistics(walltime, _), use get_time(Time). This returns a wall time stamp as a float. The resolution of the reported time depends on the OS. The walltime statistics originates from Quintus compatibility.

Run prolog program multiple times in sequence?

I have a prolog program of which I'm trying to do some analysis and establish the runtime. As time/1 gives the values in seconds, I'm just getting 0 recorded as it is not fine grain enough.
My plan to get around this is to run my Prolog program say 1000 times, find the runtime of this then simply divide by 1000 to give the runtime of the actual program.
How do you run a prolog program multiple times to have this effect?
Use for example:
?- between(1, 1 000, _),
your_goal,
false.

Get predicate execution time in seconds

I'm looking a way to get the time execution of a predicate in seconds, using swi-prolog. I found the time(X) who brings me this information and much more, but what I need is only the time in seconds, wath I would like to write after run the predicate.
There is a way to do that?
To get the elapsed runtime passed while executing a specified goal you can use call_time/2:
?- call_time(true,T_ms).
T_ms = 0.
Be aware that T_ms measures milliseconds, not seconds!
To get to seconds use an additional goal like T is T_ms * 0.001.
For a list of concrete uses of call_time/2, look at these search results.

freeze/2 goals blocking on variables that have become unreachable

I made the following little program to determine if the memory used for goals like freeze(X,Goal) is reclaimed when X becomes unreachable:
%:- use_module(library(freeze)). % Ciao Prolog needs this
freeze_many([],[]).
freeze_many([_|Xs],[V|Vs]) :-
freeze(V,throw(error(uninstantiation_error(V),big_freeze_test/3))),
freeze_many(Xs,Vs).
big_freeze_test(N0,N,Zs0) :-
( N0 > N
-> true
; freeze_many(Zs0,Zs1),
N1 is N0+1,
big_freeze_test(N1,N,Zs1)
).
Let's run the following query...
?- statistics, length(Zs,1000), big_freeze_test(1,500,Zs), statistics.
... with different Prolog processors and look at memory consumption.
What a difference!
(AMD64) SICStus Prolog 4.3.2 : global stack in use = 108 MB
(AMD64) B-Prolog 8.1 : stack+heap in use = 145 MB
(i386) Ciao Prolog 1.14.2: global stack in use = 36 MB (~72 MB w/AMD64)
(AMD64) SWI-Prolog 7.3.1 : global stack in use = 0.5 MB
(AMD64) YAProlog 6.2.2 : global stack in use = 16 MB
When running more iterations with ?- length(Zs,1000), big_freeze_test(1,10000,Zs)., I made the following observations:
Ciao Prolog reports {ERROR: Memory allocation failed [in Realloc()]} before aborting.
sicstus-prolog and b-prolog allocate more and more until the machine freezes.
swi-prolog performs all iterations in 3.554 seconds.
yap also performs all iterations, but takes 36.910 seconds.
Any ideas why it works with SWI-Prolog and YAProlog, but not with the other ones?
Considering runtime, how come SWI-Prolog beats YAProlog by more than an order of magnitude?
My intuition is leaning towards the interaction of "attributed variables" with "garbage collection". SWI-Prolog and YAProlog have (share?) a different attributed variable API and implementation than the other Prolog processors ... and, then again, it could be something completely different.
Thank you!
TL;DR: bug in SWI no more!
You are creating 500,000 frozen goals which are subsequently unreachable. What do these goals mean? Prolog systems do not analyze a goal as to its semantic relevance (prior to actually executing it). So we have to assume that the goals may be semantically relevant. As the goals are already disconnected, the only semantic effect they might have is to be false and thus making the next answer false.
So it is sufficient to consider freeze(_,false) instead.
Semantically, the predicates p/0 and q/0 are equivalent:
p :-
false.
q :-
freeze(_,false).
Procedurally, however, the first goal fails whereas the second succeeds. It is in such situations key to distinguish between solutions and answers. When Prolog succeeds, it produces an answer — most commonly this is known as an answer substitution in Prolog without constraints, where answer substitutions always contain one or infinitely many solutions1. In the presence of constraints or crude coroutining, an answer may now contain frozen goals or constraints that have to be taken into account to understand which solutions are actually described.
In the case above, the number of solutions is zero. When a system now garbage collects those frozen goals, it actually changes the meaning of the program.
In SICStus this is shown as follows:
| ?- q.
prolog:freeze(_A,user:false) ? ;
no
In SWI and YAP, those goals are not shown by default and thus chances are that bugs as this one have not been discovered.
PS: In the past, there has been a comparison between various systems concerning GC and constraints with SICStus being at that time the only one that passed all tests. In the meantime some systems improved.
I first looked at the SICStus numbers: 216 bytes per freeze! That's 27 words with 13 just for the term representing the goal. So simply 14 words for the freeze. Not so bad.
PPS: the frozen goal was throw/2, it should have been throw/1
Fine print
1: Some examples: An answer substitution X = 1 contains exactly one solution, and X = [_A] contains infinitely many solutions like X = [a] and many, many more. All this gets much more complex in the context of constraints.

calculating an algorithm time in prolog

I am solving Bridge and Torch puzzle by PROLOG. As I am trying different search methods, I need to find the calculation time. I mean the start time and the end time of solving the problem by the algorithm.
Can I have access to System time from Prolog ? How?
I calculated overall Time in a predicate using get_time(T) as this:
print_solution :-
**get_time(T1),**
init(State),
solve(State,Solution,EndState),
writeln('Start state:'),
writeln(State),
writeln('Solution:'),
writeln(Solution),
writeln('Final state:'),
writeln(EndState),
**get_time(T2),**
**DeltaT is T2- T1,**
**write('time: '), write(DeltaT), write(' ms.\n'), nl.**
Using get_time/1 for assessing the execution time of algorithms does not calculate the execution time of the algorithm in isolation, but of your entire computer's process stack. E.g., if your OS decides to run some process in the background, this can already change the time delta considerably.
SWI-Prolog has dedicated support for tracking the time spend on calculating all called predicates. For this you need to (1) import library statistics and (2) enclose the predicate you want to profile in profile/1.
For example:
:- use_module(library(statistics)).
run_test:-
profile(my_predicate(MyArgument)).
Hope this helps!

Resources