ANN: Dogelog Runtime, Prolog to the Moon (2021)

[Mostowski Collapse]

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 
>> <janburse at 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
>>
>