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

[Mostowski Collapse]

But the end-result is still very weak:
% Wall 33810 ms, gc 980 ms, 284108 lips 

This is below 1 million LIPS. 
The JavaScript version of Dogelog does currently around 2 million LIPS. 
And SWI-Prolog can do around 20 million LIPS.

Mostowski Collapse schrieb am Mittwoch, 15. September 2021 um 23:29:48 UTC+2:
> Thank you for the suggestion. The test harness 
> is invoked as follows. So it does already do time/1, 
> thats also how I did the comparison Standard Python 
> 
> and GraalVM Python, a file dogelog.py: 
> 
> import sys 
> # sys.path.append("<path>\jekrun_bench\core\harness2\libpy") 
> sys.path.append("/mnt/c/<path>/jekrun_bench/core/harness2/libpy") 
> from index import init, consult 
> 
> init() 
> consult(":- ['suite2.p']. " 
> ":- time(suite). " 
> ":- nl. " 
> ":- time(suite). ") 
> 
> Here you see a GraalVM cold and warm run.The warm run is faster. 
> If you do a warm warm run, it even gets more faster, because of 
> JIT-ing, Just-in-Time machine compilation, 
> 
> via the GraalVM Truffles framework: 
> 
> $ export PATH=<path>/graalvm-ce-java8-21.2.0/bin:$PATH 
> $ cd /mnt/c/<path>/jekrun_bench/core/harness2 
> $ graalpython /mnt/c/<path>/jekrun_bench/core/harness2/dogelog.py 
> nrev % Wall 6175 ms, gc 212 ms, 154473 lips 
> crypt % Wall 9327 ms, gc 63 ms, 112838 lips 
> deriv % Wall 4101 ms, gc 90 ms, 321890 lips 
> poly % Wall 3594 ms, gc 415 ms, 216299 lips 
> sortq % Wall 3427 ms, gc 67 ms, 290070 lips 
> tictac % Wall 2770 ms, gc 51 ms, 136580 lips 
> queens % Wall 3287 ms, gc 64 ms, 325617 lips 
> query % Wall 1432 ms, gc 77 ms, 382969 lips 
> mtak % Wall 2532 ms, gc 95 ms, 533881 lips 
> perfect % Wall 3980 ms, gc 76 ms, 290382 lips 
> % Wall 40745 ms, gc 1212 ms, 235751 lips 
> 
> nrev % Wall 4508 ms, gc 112 ms, 211595 lips 
> crypt % Wall 6063 ms, gc 61 ms, 173584 lips 
> deriv % Wall 3150 ms, gc 42 ms, 419070 lips 
> poly % Wall 3549 ms, gc 432 ms, 219042 lips 
> sortq % Wall 3196 ms, gc 63 ms, 311036 lips 
> tictac % Wall 2670 ms, gc 52 ms, 141695 lips 
> queens % Wall 3087 ms, gc 60 ms, 346713 lips 
> query % Wall 1434 ms, gc 25 ms, 382435 lips 
> mtak % Wall 2596 ms, gc 90 ms, 520719 lips 
> perfect % Wall 3521 ms, gc 43 ms, 328236 lips 
> % Wall 33810 ms, gc 980 ms, 284108 lips
> DFS schrieb am Mittwoch, 15. September 2021 um 23:15:07 UTC+2: 
> > On 9/15/2021 12:23 PM, Mostowski Collapse wrote: 
> > > I really wonder why my Python implementation 
> > > is a factor 40 slower than my JavaScript implementation. 
> > > Structurally its the same code. 
> > > 
> > > You can check yourself: 
> > > 
> > > Python Version: 
> > > https://github.com/jburse/dogelog-moon/blob/main/devel/runtimepy/machine.py 
> > > 
> > > JavaScript Version: 
> > > https://github.com/jburse/dogelog-moon/blob/main/devel/runtime/machine.js 
> > > 
> > > Its the same while, if-then-else, etc.. its the same 
> > > classes Variable, Compound etc.. Maybe I could speed 
> > > it up by some details. For example to create an array 
> > > of length n, I use in Python: 
> > > 
> > > temp = [NotImplemented] * code[pos] 
> > > pos += 1 
> > > 
> > > Whereas in JavaScript I use, also 
> > > in exec_build2(): 
> > > 
> > > temp = new Array(code[pos++]); 
> > > 
> > > So I hear Guido doesn't like ++. So in Python I use += 
> > > and a separate statement as a workaround. But otherwise, 
> > > what about the creation of an array, 
> > > 
> > > is the the idiom [_] * _ slow? I am assuming its 
> > > compiled away. Or does it really first create an 
> > > array of size 1 and then enlarge it? 
> > I'm sure you know you can put in timing statements to find bottlenecks. 
> > 
> > import time 
> > startTime = time.perf_counter() 
> > [code block] 
> > print("%.2f" % (time.perf_counter() - startTime))