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

[Mostowski Collapse]

Also I am not a C programmer. The last time I was programming C 
was 30 years ago. I am mostly a Java programmer the recent years. 
Dogelog Runtime adopts a lot of implementation details from

Jekejeke Prolog which is a Prolog written in Java. The difference
betweeen the two is that Jekejeke Prolog has another Prolog term
model where Prolog terms are passed around as molecs, which

are pairs of skeleton and display. On the other in Dogelog Runtime
uses a simpler representation, Prolog terms are passed around
as only one object. Programming language wise the difference 

between using Java and JavaScript or Python, is that Java has
types. So variables need a type declaration. Otherwise Java is
very similar to JavaScript or Python, it also provides a runtime with

a garbage collection. The idea I would use C-style is a little absurd. It 
would also require that a free() objects manually. But sweep_trail() has 
nothing to do with freeing objects manually, its the anti-thesis to 

freeing objects manually, its a Prolog garbage collector after all!

Mostowski Collapse schrieb am Montag, 20. September 2021 um 14:36:01 UTC+2:
> 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