The Prolog garbage collection that does
the movement on the variable trail is only
a very small fraction of the runtime.
The garbage collection time is measured.
Some measurements with version 0.9.5
took the following values:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Standard Python Version, Warm Run
% ?- time(fibo(23,X)).
% % Wall 3865 ms, gc 94 ms, 71991 lips
% X = 46368.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% GraalVM Python Version, Warm Warm Run
% ?- time(fibo(23,X)).
% % Wall 695 ms, gc 14 ms, 400356 lips
% X = 46368.
The "gc" timing measures Prolog garbage
collection. So you get the following percentage
of time spent in Prolog garbage collection:
Standard Python: 94 / 3865 = 2.4%
GraalVM Python: 14 / 695 = 2.0%
I consider this a good result. The Prolog
garbage collection is not utterly expensive.
The detecting the movement and performing
the variable movement on the trail, doesn't
take so much time. Currently the garbage collection
in Dogelog runtime is configured towards
synchronization with 60FPS, it does around
60-120 garbage collections per second. This
is less than what SWI-Prolog does.
SWI-Prolog has a much higher GC rate.
But I did not yet measure new version 0.9.6.
Mostowski Collapse schrieb:
No its cooperative. Usually objects do get
garbage collected by the native garbage collector
of the host language in Dogelog runtime.
The Prolog garbage collection is only to help
the host language garbage collector when you have
a deep recursion in Prolog.
You can then reclaim intermediate variables.
A simple example to test the slightly idio-
syncratic Prolog garbage collection is:
fibo(0, 1) :- !.
fibo(1, 1) :- !.
fibo(N, X) :-
M is N-1, fibo(M, Y),
L is M-1, fibo(L, Z),
X is Y+Z.
When running fibo(30,X) SWI-Prolog does around
800 garbage collections to keep the environment
small. But SWI-Prolog allocates all its objects
only very seldom on the heap. It uses its own
stack. On the other hand Dogelog runtime creates
everything on the heap. And completely relies on
the host language garbage collection. It only
helps the host language garbage collection it
that it performs from time to time this movement:
Before:
-->[ A ]-->[ B ]-->[ C ]-->
After:
-->[ A ]---------->[ C ]-->
A,B,C are objects of type Variable. The above
movement only happens for objects of type Variables
from time to time. For objects of type Compound
no modifications are done during Prolog garbage
collection. The Prolog garbage collection aggressively
nulls the Variable object B, and the host language
later will garbage collect what the Variable object B
was pointing to. But the Variable object B might
nevertheless have point to something shared with
some other Variable object or a local or a global
Python variable, or a Compound. This is then all
courtesy of the host language to decide reachability.
Chris Angelico schrieb:
On Fri, Sep 17, 2021 at 7:17 AM Mostowski Collapse
<janbu...@fastmail.fm> wrote:
About Exceptions: Thats just building ISO core
standard Prolog error terms.
About Garbage Collection: Thats just Prolog
garbage collection, which does shrink some
single linked lists, which ordinary
programmig language GC cannot do,
Okay, so.... you're building your own garbage collection on top of
Python's, and you're wondering why it's slow?
Change your code to not try to implement one language inside another,
and you'll see a massive performance improvement.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
