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))
--
https://mail.python.org/mailman/listinfo/python-list
