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

[Mostowski Collapse]

But I dont see any utility in investing too much time with
the Prolog garbage collection of Dogelog runtime. It is
only a small share of the execution time:

Mostowski Collapse schrieb am Freitag, 17. September 2021 um 10:58:57 UTC+2:
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
> % 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% 

If you spare these 2-3% it will not speed-up Dogelog runtime.
The Prolog garbage collection is there to allow Erlang
processes. And its also there to allow more Prolog search

without exhausting the memory. But it cost you only 2-3%
judging from the Fibonnacci Numbers example. Need to
check with other examples whether its higher.

But since the ratio between Garbage and non-Garbage is
usually high, and non-Garbage is easily identified, and
the Garbage is also easily removed, the time will

possibly not exceed much more than the same 2-3% for
other examples. So in conclusion I am least worried
about the Prolog garbage collection. You guys are only

worried because its something new. But its nothing that
does any harm and costs a lot, it only does good and
is very cheap in terms of extra runtime effort.

Mostowski Collapse schrieb am Montag, 20. September 2021 um 08:44:49 UTC+2:
> This strategy works if you use failure driven loops. 
> It doesn't work you program recursive loops that go 
> on forever. Like Erlang processes. 
> 
> foo(X) :- 
> bar(X,Y), foo(Y). 
> 
> Typically Y is a fresh variable. A good Prolog system 
> with good Garbage Collection can run such a process 
> for days and months. 
> 
> If you don't clean up the trail, you exhaust the 
> memory after a few minutes or seconds. 
> 
> Greg Ewing schrieb:
> >> On Mon, Sep 20, 2021 at 3:19 AM Mostowski Collapse 
> >> <janb... at fastmail.fm> wrote: 
> >>> 
> >>> On the other hand if I would use the trigger 
> >>> from Python, I possibly would need a double linked 
> >>> list, to remove an element. 
> > 
> > Here's another idea: Put weak references in the trail, but 
> > don't bother with the scanning -- just skip over dead ones 
> > during backtracking. 
> > 
> > Seems to me you would be doing about the same amount of 
> > work either way, just doing it at different times. 
> >