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

[Mostowski Collapse]

The sweep_trail() is not an issue. There must be a bottleneck
somewhere else in Python. The sweep_trail() respectively the 
paremt call gc() only takes a very small fraction of the runtime:

Check the "gc" timing, the bottleneck is somewhere else?

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. 

Also my code is not C-style. If I would use C-style code, I would
use address calculations and the adress operator &. But you
don't find and according C-style in the Python or JavaScript code.

Also there is no substitute for such coding style in the for
of value holders or some such. Its all plain Python respectively
JavaScript not at all inspired by the C programming language.

The single linked list is not some indicative of C programming
language style. With C programming language sytle one would
do other tricks, you cannot read off from my Python or JavaScript

code, since I cannot apply them to Python or JavaScript. Among
the other C programming language tricks not available in Python
or JavaScript would for example be inlining the args in Compound

and so on. But I am not sure whether this is the bottleneck.

Chris Angelico schrieb am Montag, 20. September 2021 um 14:25:12 UTC+2:
> On Mon, Sep 20, 2021 at 9:50 PM Peter J. Holzer <hjp-p... at hjp.at> wrote: 
> > > Let Python be Python, don't try to build your own language on top of 
> > > it. 
> > 
> > Well, he's writing a Prolog interpreter, so building his own language on 
> > top of Python is sort of the point. I think a better way to put it is 
> > "Don't try to write Python as if it was C".
> Fair point. Or combining them both: Writing a language interpreter in 
> Python as if you were writing it in C, and then complaining that it is 
> slow, is only going to elicit "well uhh yes?" responses. 
> 
> Languages like NetRexx (and, I think, Jython, although I can't find 
> any definitive and current answers) are slightly different from their 
> "parent" languages, because they make good use of their implementation 
> languages' features. This Prolog interpreter might not even need to be 
> different in functionality, but its implementation would be different, 
> and it could take advantage of the underlying garbage collection. 
> 
> ChrisA