Mailing List Archive

Woa! The JavaScript JIT compiler is quite impressive. I now
ported Dogelog runtime to Python as well, so that I can compare
JavaScript and Python, and tested without clause indexing:

between(L,H,L) :- L =< H.
between(L,H,X) :- L < H, Y is L+1, between(Y,H,X).

setup :- between(1,255,N), M is N//2, assertz(edge(M,N)), fail.
setup :- edge(M,N), assertz(edge2(N,M)), fail.
setup.

anc(X,Y) :- edge(X, Y).
anc(X,Y) :- edge(X, Z), anc(Z, Y).

anc2(X,Y) :- edge2(Y, X).
anc2(X,Y) :- edge2(Y, Z), anc2(X, Z).

:- setup.
:- time((between(1,10,_), anc2(0,255), fail; true)).
:- time((between(1,10,_), anc(0,255), fail; true)).

The results are:

/* Python 3.10.0rc1 */
% Wall 188 ms, trim 0 ms
% Wall 5537 ms, trim 0 ms

/* JavaScript Chrome 92.0.4515.159 */
% Wall 5 ms, trim 0 ms
% Wall 147 ms, trim 0 ms
--
https://mail.python.org/mailman/listinfo/python-list

Thats a factor 37.8 faster! I tested the a variant of
the Albufeira instructions Prolog VM aka ZIP, which
was also the inspiration for SWI-Prolog.

Open Source:

The Python Version of the Dogelog Runtime
https://github.com/jburse/dogelog-moon/tree/main/devel/runtimepy

The Python Test Harness
https://gist.github.com/jburse/bf6c01c7524f2611d606cb88983da9d6#file-test-py


Mostowski Collapse schrieb:
> Woa! The JavaScript JIT compiler is quite impressive. I now
> ported Dogelog runtime to Python as well, so that I can compare
> JavaScript and Python, and tested without clause indexing:
>
> between(L,H,L) :- L =< H.
> between(L,H,X) :- L < H, Y is L+1, between(Y,H,X).
>
> setup :- between(1,255,N), M is N//2, assertz(edge(M,N)), fail.
> setup :- edge(M,N), assertz(edge2(N,M)), fail.
> setup.
>
> anc(X,Y) :- edge(X, Y).
> anc(X,Y) :- edge(X, Z), anc(Z, Y).
>
> anc2(X,Y) :- edge2(Y, X).
> anc2(X,Y) :- edge2(Y, Z), anc2(X, Z).
>
> :- setup.
> :- time((between(1,10,_), anc2(0,255), fail; true)).
> :- time((between(1,10,_), anc(0,255), fail; true)).
>
> The results are:
>
> /* Python 3.10.0rc1 */
> % Wall 188 ms, trim 0 ms
> % Wall 5537 ms, trim 0 ms
>
> /* JavaScript Chrome 92.0.4515.159 */
> % Wall 5 ms, trim 0 ms
> % Wall 147 ms, trim 0 ms

--
https://mail.python.org/mailman/listinfo/python-list

We = Me and my cat named socrates
The cat is a very good programmer:

def meow():
print("meow meow, Prolog is not only SWI-Prolog")

Julio Di Egidio schrieb:
> On Sunday, 15 August 2021 at 14:43:42 UTC+2, Mostowski Collapse wrote:
>
>> Yesterday we went into a little programming binge
>
> Who is this "we"?
>
>> See also:
>>
>> Python Version of Dogelog Runtime special
>> https://twitter.com/dogelogch/status/1426884473988292617
>>
>> Python Version of Dogelog Runtime special
>> https://www.facebook.com/groups/dogelog
>
> I haven't tried either but, assuming the code works ;), great stuff man.
>
> You might be the one(s) who save Prolog from oblivion...
>
> Julio
>

--
https://mail.python.org/mailman/listinfo/python-list

The world is getting ridiculous. termux seems to
not anymore be supported by Google Play because
of some Android 10 issues?

On the other hand there is this gem:

TI 84 Plus CE Python Edition Unboxing
https://www.youtube.com/watch?v=LVxP_Fki8Fc

LoL

Mostowski Collapse schrieb:
> Yesterday we went into a little programming binge, despite there
> was a free parade in Zurich. We could now already implement a transpiler
> that targets Python. We simply took the transpiler main.p that targets
>
> JavaScript and moded it into a new transpiler mainpy.p that targets
> Python. The code is already on GitHub and we present it also here
> as the Python code mainpy.p. We were also busy
>
> on machine.py and special.py. The progress is now:
>
> +------------+   cross      +-------------+
> | loader.p   |   compile    | loader.py   | 100%
> | compiler.p | -----------> | compiler.py | 100%
> +------------+              +-------------+
>                             | machine.py  |  66%
>                             | special.py  |  33%
>                             +-------------+
>
> See also:
>
> Python Version of Dogelog Runtime special
> https://twitter.com/dogelogch/status/1426884473988292617
>
> Python Version of Dogelog Runtime special
> https://www.facebook.com/groups/dogelog

--
https://mail.python.org/mailman/listinfo/python-list

Having fun with a new attended query answerer for
the Dogelog runtime. It can be bottled into a single Python
file, no server roundtrip, just ISO core Prolog in one

Python file, requires Python 3.10:

>python.exe toplevel.py
Dogelog Runtime, Prolog to the Moon, 0.9.3
(c) 1985-2021, XLOG Technologies AG, Switzerland
?- X=1; X=2.
X = 1;
X = 2.
?- X= ... ; X = ... .
X = ...;
X = ... .
?-

So we adopted displaying a dot when there are no more
choice points. This is seen in SWI-Prolog for example, but
was also adopted by Scryer Prolog recently.

Note the space between '...' and '.' in the last answer of
the last query. This is needed so that what is shown
is copyable. The query answerer is described here:

Dogelog Runtime attended Prolog query answers. (Jekejeke)
https://twitter.com/dogelogch/status/1430647215928877065

Dogelog Runtime attended Prolog query answers. (Jekejeke)
https://www.facebook.com/groups/dogelog
--
https://mail.python.org/mailman/listinfo/python-list

More best kept secrets of Prolog: Pattern Matching

Everybody loves pattern matching. Languages
like Python, release 3.10, even provide it
now. There is now a match/case statement

in Python. But Prolog users will scratch their
head. Will my if-then-else be as fast as a
imperative switch jump table lookup?

Dogelog runtime has stepped up its game
concerning pattern matching. It now provides
ECLiPSe Prolog disjunction and if-then-else

indexing. Take this example:

?- [user].
foo(X,Y) :- X=baz, Y=2; X=bar -> Y=1.

SWI-Prolog leaves a choice point, so no
clause indexing used:

/* SWI-Prolog 8.3.26 */
?- foo(baz,Z).
Z = 2 ; %%% Spurious Choice Point
false.

Dogelog doesn't leave a choice point, since
it can index the disjunction and if-then-else:

/* Dogelog Runtime 0.9.3 */
?- foo(baz,Z).
Z = 2. %%% No Choice Point

See also:

Preview: Dogelog disjunction and if-then-else indexing. (Jekejeke)
https://twitter.com/dogelogch/status/1433446729974796293

Preview: Dogelog disjunction and if-then-else indexing. (Jekejeke)
https://www.facebook.com/groups/dogelog
--
https://mail.python.org/mailman/listinfo/python-list

The Standard Python version of Dogelog runtime
is annoyingly slow. So we gave it a try with
andother Python, and it was 6x times faster.

We could test GraalVM. We worked around the missing
match in Python 3.8 by replacing it with if-then-else.
Performance is a little better, we find:

/* 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.

See also:

JDK 1.8 GraalVM Python is 6x faster than Standard Python
https://twitter.com/dogelogch/status/1437395917167112193

JDK 1.8 GraalVM Python is 6x faster than Standard Python
https://www.facebook.com/groups/dogelog

Mostowski Collapse schrieb:
> Yesterday we went into a little programming binge, despite there
> was a free parade in Zurich. We could now already implement a transpiler
> that targets Python. We simply took the transpiler main.p that targets
>
> JavaScript and moded it into a new transpiler mainpy.p that targets
> Python. The code is already on GitHub and we present it also here
> as the Python code mainpy.p. We were also busy
>
> on machine.py and special.py. The progress is now:
>
> +------------+   cross      +-------------+
> | loader.p   |   compile    | loader.py   | 100%
> | compiler.p | -----------> | compiler.py | 100%
> +------------+              +-------------+
>                             | machine.py  |  66%
>                             | special.py  |  33%
>                             +-------------+
>
> See also:
>
> Python Version of Dogelog Runtime special
> https://twitter.com/dogelogch/status/1426884473988292617
>
> Python Version of Dogelog Runtime special
> https://www.facebook.com/groups/dogelog

--
https://mail.python.org/mailman/listinfo/python-list

On 9/13/2021 8:46 AM, Mostowski Collapse wrote:
> The Standard Python version of Dogelog runtime
> is annoyingly slow. So we gave it a try with
> andother Python, and it was 6x times faster.
>
> We could test GraalVM. We worked around the missing
> match in Python 3.8 by replacing it with if-then-else.
> Performance is a little better, we find:
>
> /* 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.
>
> See also:
>
> JDK 1.8 GraalVM Python is 6x faster than Standard Python
> https://twitter.com/dogelogch/status/1437395917167112193
>
> JDK 1.8 GraalVM Python is 6x faster than Standard Python
> https://www.facebook.com/groups/dogelog

You need to test more than fibonacci to make that claim. There is a
benchmark test that times around 40 different similarly small benchmarks.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

I am testing a Prolog interpreter written
in Python. So fibonacci number routine is
written in Prolog and I am running the

fibonnaci number routine inside the
Prolog interpreter that is written in
Python. The factor 6x times faster of

GraalVM can be reproduced also for other
Prolog programs running inside the Prolog
interpreter that is written in Python.

I have a benchmark suite, where I get,
the figures are milliseconds:

Test Standard GraalVM
Total 170'996 28'523

This means the factor is:

170'996 / 28'523 = 5.9950

The test harness, test cases and individual
results for all test cases are found here:

And we could test GraalVM Python, results are from 14.09.2021,
tested with Dogelog Runtime 0.9.5, Python Version:
https://gist.github.com/jburse/f4e774ebb15cac722238b26b1a620f84#gistcomment-3892587

Terry Reedy wrote:
> On 9/13/2021 8:46 AM, Mostowski Collapse wrote:
>> The Standard Python version of Dogelog runtime
>> is annoyingly slow. So we gave it a try with
>> andother Python, and it was 6x times faster.
>>
>> We could test GraalVM. We worked around the missing
>> match in Python 3.8 by replacing it with if-then-else.
>> Performance is a little better, we find:
>>
>> /* 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.
>>
>> See also:
>>
>> JDK 1.8 GraalVM Python is 6x faster than Standard Python
>> https://twitter.com/dogelogch/status/1437395917167112193
>>
>> JDK 1.8 GraalVM Python is 6x faster than Standard Python
>> https://www.facebook.com/groups/dogelog
>
> You need to test more than fibonacci to make that claim.  There is a
> benchmark test that times around 40 different similarly small benchmarks.
>
>

--
https://mail.python.org/mailman/listinfo/python-list

But even when using GraalVM Python, the
execution is still slow. Much slower
then the same Prolog interpreter written

in JavaScript. For JavaScript node.exe
I get much better results. I get these
results comparing to a few other new

Prolog systems as well:

Test Dogelog Scryer Trealla
Total 4427 7325 1824

The test harness, test cases and individual
results for all test cases are found here:

Meanwhile could also test Trealla, results are from 12.09.2021,
tested with Dogelog Runtime 0.9.5, JavaScript Version:
https://gist.github.com/jburse/f4e774ebb15cac722238b26b1a620f84#gistcomment-3890013

But this is all only a moment in time.
The Prolog interpreter itself is evolving,
and the programming languages also,

so this is a moving target. Benchmark
results will look different tomorrow.

Mostowski Collapse wrote:
> I am testing a Prolog interpreter written
> in Python. So fibonacci number routine is
> written in Prolog and I am running the
>
> fibonnaci number routine inside the
> Prolog interpreter that is written in
> Python. The factor 6x times faster of
>
> GraalVM can be reproduced also for other
> Prolog programs running inside the Prolog
> interpreter that is written in Python.
>
> I have a benchmark suite, where I get,
> the figures are milliseconds:
>
> Test    Standard    GraalVM
> Total     170'996      28'523
>
> This means the factor is:
>
> 170'996 / 28'523 = 5.9950
>
> The test harness, test cases and individual
> results for all test cases are found here:
>
> And we could test GraalVM Python, results are from 14.09.2021,
> tested with Dogelog Runtime 0.9.5, Python Version:
> https://gist.github.com/jburse/f4e774ebb15cac722238b26b1a620f84#gistcomment-3892587
>
>
> Terry Reedy wrote:
>> On 9/13/2021 8:46 AM, Mostowski Collapse wrote:
>>> The Standard Python version of Dogelog runtime
>>> is annoyingly slow. So we gave it a try with
>>> andother Python, and it was 6x times faster.
>>>
>>> We could test GraalVM. We worked around the missing
>>> match in Python 3.8 by replacing it with if-then-else.
>>> Performance is a little better, we find:
>>>
>>> /* 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.
>>>
>>> See also:
>>>
>>> JDK 1.8 GraalVM Python is 6x faster than Standard Python
>>> https://twitter.com/dogelogch/status/1437395917167112193
>>>
>>> JDK 1.8 GraalVM Python is 6x faster than Standard Python
>>> https://www.facebook.com/groups/dogelog
>>
>> You need to test more than fibonacci to make that claim.  There is a
>> benchmark test that times around 40 different similarly small benchmarks.
>>
>>
>

--
https://mail.python.org/mailman/listinfo/python-list

Opinion: Anyone who is counting on Python for truly fast compute speed is probably using Python for the wrong purpose.
Here, we use Python to control Test Equipment, to set up the equipment and ask for a measurement, get it, and proceed to the next measurement; and at the end produce a nice formatted report. If we wrote the test script in C or Rust or whatever it could not run substantially faster because it is communicating with the test equipment, setting it up and waiting for responses, and that is where the vast majority of the time goes. Especially if the measurement result requires averaging it can take a while. In my opinion this is an ideal use for Python, not just because the speed of Python is not important, but also because we can easily find people who know Python, who like coding in Python, and will join the company to program in Python ... and stay with us.

--- Joseph S.


Teledyne Confidential; Commercially Sensitive Business Data

-----Original Message-----
From: Mostowski Collapse <janburse@fastmail.fm>
Sent: Tuesday, September 14, 2021 8:56 AM
To: python-list@python.org
Subject: Re: ANN: Dogelog Runtime, Prolog to the Moon (2021)

I am testing a Prolog interpreter written in Python. So fibonacci number routine is written in Prolog and I am running the

fibonnaci number routine inside the
Prolog interpreter that is written in
Python. The factor 6x times faster of

GraalVM can be reproduced also for other Prolog programs running inside the Prolog interpreter that is written in Python.

I have a benchmark suite, where I get,
the figures are milliseconds:

Test Standard GraalVM
Total 170'996 28'523

This means the factor is:

170'996 / 28'523 = 5.9950

The test harness, test cases and individual results for all test cases are found here:

And we could test GraalVM Python, results are from 14.09.2021, tested with Dogelog Runtime 0.9.5, Python Version:
https://gist.github.com/jburse/f4e774ebb15cac722238b26b1a620f84#gistcomment-3892587

Terry Reedy wrote:
> On 9/13/2021 8:46 AM, Mostowski Collapse wrote:
>> The Standard Python version of Dogelog runtime is annoyingly slow. So
>> we gave it a try with andother Python, and it was 6x times faster.
>>
>> We could test GraalVM. We worked around the missing match in Python
>> 3.8 by replacing it with if-then-else.
>> Performance is a little better, we find:
>>
>> /* 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.
>>
>> See also:
>>
>> JDK 1.8 GraalVM Python is 6x faster than Standard Python
>> https://twitter.com/dogelogch/status/1437395917167112193
>>
>> JDK 1.8 GraalVM Python is 6x faster than Standard Python
>> https://www.facebook.com/groups/dogelog
>
> You need to test more than fibonacci to make that claim.  There is a
> benchmark test that times around 40 different similarly small benchmarks.
>
>

--
https://mail.python.org/mailman/listinfo/python-list

I am not testing this use-case. But a related
use-case might highlight why speed did never
hurt anybody.

Lets say you program a flying drone with Python,
and the measurement is from the drone sensor
and communication systems.

Lets say you are using the idle time between
measurements for some complex planning. It
is then not true that you have anyway

to wait for the measurement.

Hope this helps!

BTW: If somebody knows another Python implementation
I am happy to test this implementation as well.
I am assuming that the standard Python python.exe

I tested amounts to CPython? Not sure. And the
GraalVM is practically the same as JPython? Not
sure either.

> Opinion: Anyone who is counting on Python
> for truly fast compute speed is probably using
> Python for the wrong purpose.
> Here, we use Python to control Test Equipment,
> to set up the equipment and ask for a measurement,
> get it, and proceed to the next measurement; and
> at the end produce a nice formatted report.
> If we wrote the test script in C or Rust or
> whatever it could not run substantially faster
> because it is communicating with the test equipment,
> setting it up and waiting for responses, and
> that is where the vast majority of the time goes.
> Especially if the measurement result requires
> averaging it can take a while. In my opinion
> this is an ideal use for Python, not just because
> the speed of Python is not important, but also
> because we can easily find people who know Python,
> who like coding in Python, and will join the
> company to program in Python ... and stay with us.
>
> --- Joseph S.

--
https://mail.python.org/mailman/listinfo/python-list

Oops "speed did never hurt anybody". Don't be
evil, I am talking about unarmed drones.

See also:

Drone Programming With Python Course
https://www.youtube.com/watch?v=LmEcyQnfpDA

Mostowski Collapse schrieb:
> I am not testing this use-case. But a related
> use-case might highlight why speed did never
> hurt anybody.
>
> Lets say you program a flying drone with Python,
> and the measurement is from the drone sensor
> and communication systems.
>
> Lets say you are using the idle time between
> measurements for some complex planning. It
> is then not true that you have anyway
>
> to wait for the measurement.
>
> Hope this helps!
>
> BTW: If somebody knows another Python implementation
> I am happy to test this implementation as well.
> I am assuming that the standard Python python.exe
>
> I tested amounts to CPython? Not sure. And the
> GraalVM is practically the same as JPython? Not
> sure either.
>
>> Opinion:   Anyone who is counting on Python for truly fast compute
>> speed is probably using Python for the wrong purpose. Here, we use
>> Python to control Test Equipment, to set up the equipment and ask for
>> a measurement, get it, and proceed to the next measurement; and at the
>> end produce a nice formatted report. If we wrote the test script in C
>> or Rust or whatever it could not run substantially faster because it
>> is communicating with the test equipment, setting it up and waiting
>> for responses, and that is where the vast majority of the time goes.
>> Especially if the measurement result requires averaging it can take a
>> while.  In my opinion this is an ideal use for Python, not just
>> because the speed of Python is not important, but also because we can
>> easily find people who know Python, who like coding in Python, and
>> will join the company to program in Python ... and stay with us.
>> --- Joseph S.
>

--
https://mail.python.org/mailman/listinfo/python-list

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?

Julio Di Egidio wrote:
> On Wednesday, 15 September 2021 at 15:37:19 UTC+2, Mostowski Collapse wrote:
>
>>> Opinion: Anyone who is counting on Python
>>> for truly fast compute speed is probably using
>>> Python for the wrong purpose.
>
> You just don't know anything about this environment: those who need fast computation rather use *libraries* where all the performance critical parts are written in native code... and that's pretty customary in Python.
>
> By that I don't mean Python is flawless, indeed (IMO) it isn't in so many ways: to the point that, for more professional solutions in the maths/statistics realms in particular, people rather use R: yet, the primary reason is not so much performance but really the solidity/structure of the language per se...
>
> Julio
>

--
https://mail.python.org/mailman/listinfo/python-list

On Thu, Sep 16, 2021 at 3:17 AM Mostowski Collapse <janburse@fastmail.fm> wrote:
>
> I really wonder why my Python implementation
> is a factor 40 slower than my JavaScript implementation.
> Structurally its the same code.
>

Very hard to know. Your code is detailed and complicated. Do they
produce identical results? Are you using the same sort of
floating-point data everywhere, or is one integer and the other float?
What's going on with all the globals, the continuations, etc? My
suspicion is that you're trying to write weird, wonky Python code, and
then are surprised that it doesn't perform well.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

If you find a "wonky" spot, I can replace it by "non-wonky"
code. I noticed some differences between Python Dicts
and JavaScript objects. Python tends to throw more exceptions.

So in Python I now do the following:

peek = kb.get(functor, NotImplemented)
if peek is not NotImplemented:

In JavaScript I can directly do:

peek = kb[functor];
if (peek !== undefined)

But if get() in Python is implemented under the hood with
exception handling. i.e. using the exception prone [] and
then in case an exception is thrown, returning the

default value, then Python get() will probably be quite slow.
Since usually exceptions are slow.

Chris Angelico schrieb am Mittwoch, 15. September 2021 um 19:27:13 UTC+2:
> On Thu, Sep 16, 2021 at 3:17 AM Mostowski Collapse <janb...@fastmail.fm> wrote:
> >
> > I really wonder why my Python implementation
> > is a factor 40 slower than my JavaScript implementation.
> > Structurally its the same code.
> >
> Very hard to know. Your code is detailed and complicated. Do they
> produce identical results? Are you using the same sort of
> floating-point data everywhere, or is one integer and the other float?
> What's going on with all the globals, the continuations, etc? My
> suspicion is that you're trying to write weird, wonky Python code, and
> then are surprised that it doesn't perform well.
>
> ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

On Wed, 15 Sep 2021 18:23:10 +0200, 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?
>
> Julio Di Egidio wrote:
<sniped due to top posting>

this is probably a string contender

i = 0
while i < len(term.args) - 1:
mark_term(term.args[i])
i += 1
term = term.args[i]

try replacing with something more pythonic

for index,term in enumerate(term.args):
mark_term(term.args[i])


& possibly go all the way to changing it into a comprehension

there are other similar anti patterns throughout this code.

any time you are manually keeping a counter as an index into a list,tupple
other iterable YOU ARE DOING IT WRONG!

Do not write javascript in python, write python



--
Two percent of zero is almost nothing.




--
Whoever dies with the most toys wins.
--
https://mail.python.org/mailman/listinfo/python-list

On Thu, 16 Sep 2021 03:26:39 +1000, Chris Angelico wrote:

> On Thu, Sep 16, 2021 at 3:17 AM Mostowski Collapse
> <janburse@fastmail.fm> wrote:
>>
>> I really wonder why my Python implementation is a factor 40 slower than
>> my JavaScript implementation.
>> Structurally its the same code.
>>
>>
> Very hard to know. Your code is detailed and complicated. Do they
> produce identical results? Are you using the same sort of floating-point
> data everywhere, or is one integer and the other float?
> What's going on with all the globals, the continuations, etc? My
> suspicion is that you're trying to write weird, wonky Python code, and
> then are surprised that it doesn't perform well.
>
> ChrisA

And this demonstrates how an experienced Python programmer can make an
almost spot on diagnosis without even checking the source code.

@ this stage I would recommend watching some presentations on you tube

this one https://www.youtube.com/watch?v=wf-BqAjZb8M by Raymond Hettinger
is brilliant as it highlights there is more to checking code than just
making sure it looks nice & runs correctly.



--
Lemmings don't grow older, they just die.
--
https://mail.python.org/mailman/listinfo/python-list

Do you mean, replace this:

i = 0
while i < len(term.args) - 1:
____mark_term(term.args[i])
____i += 1
term = term.args[i]

By this:

for i,term in enumerate(term.args):
____mark_term(term.args[i])

This wouldn't be correct anymore. The
recursive call is only for the arguments
except for the last one one.

alister schrieb am Mittwoch, 15. September 2021 um 20:17:23 UTC+2:
> On Wed, 15 Sep 2021 18:23:10 +0200, 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?
> >
> > Julio Di Egidio wrote:
> <sniped due to top posting>
>
> this is probably a string contender
>
> i = 0
> while i < len(term.args) - 1:
> mark_term(term.args[i])
> i += 1
> term = term.args[i]
>
> try replacing with something more pythonic
>
> for index,term in enumerate(term.args):
> mark_term(term.args[i])
>
>
> & possibly go all the way to changing it into a comprehension
>
> there are other similar anti patterns throughout this code.
>
> any time you are manually keeping a counter as an index into a list,tupple
> other iterable YOU ARE DOING IT WRONG!
>
> Do not write javascript in python, write python
>
>
>
> --
> Two percent of zero is almost nothing.
>
>
>
>
> --
> Whoever dies with the most toys wins.
--
https://mail.python.org/mailman/listinfo/python-list

Well I would be more than happy if an experienced
programmer can fine tune my code. My programming
experience in Python is only 4 weeks.

Mostowski Collapse schrieb am Dienstag, 14. September 2021 um 14:56:35 UTC+2:
> The test harness, test cases and individual
> results for all test cases are found here:
>
> And we could test GraalVM Python, results are from 14.09.2021,
> tested with Dogelog Runtime 0.9.5, Python Version:
> https://gist.github.com/jburse/f4e774ebb15cac722238b26b1a620f84#gistcomment-3892587

If you follow the above link, you also find:

Test Harness
https://gist.github.com/jburse/f4e774ebb15cac722238b26b1a620f84#file-suite2-pl

Test Cases
https://github.com/jburse/jekejeke-samples/tree/master/jekrun_bench/core/tests

CPU / RAM: Intel(R) Core(TM) i7-6700HQ, 32 GB
Standard Python: python.exe Python 3.10.0rc1
GraalVM Python: WSL 2, Python 3.8.5 (GraalVM CE Native 21.2.0)

alister schrieb am Mittwoch, 15. September 2021 um 20:22:56 UTC+2:
> On Thu, 16 Sep 2021 03:26:39 +1000, Chris Angelico wrote:
>
> > On Thu, Sep 16, 2021 at 3:17 AM Mostowski Collapse
> > <janb...@fastmail.fm> wrote:
> >>
> >> I really wonder why my Python implementation is a factor 40 slower than
> >> my JavaScript implementation.
> >> Structurally its the same code.
> >>
> >>
> > Very hard to know. Your code is detailed and complicated. Do they
> > produce identical results? Are you using the same sort of floating-point
> > data everywhere, or is one integer and the other float?
> > What's going on with all the globals, the continuations, etc? My
> > suspicion is that you're trying to write weird, wonky Python code, and
> > then are surprised that it doesn't perform well.
> >
> > ChrisA
> And this demonstrates how an experienced Python programmer can make an
> almost spot on diagnosis without even checking the source code.
>
> @ this stage I would recommend watching some presentations on you tube
>
> this one https://www.youtube.com/watch?v=wf-BqAjZb8M by Raymond Hettinger
> is brilliant as it highlights there is more to checking code than just
> making sure it looks nice & runs correctly.
>
>
>
> --
> Lemmings don't grow older, they just die.
--
https://mail.python.org/mailman/listinfo/python-list

There is a further problem with this:

> for i,term in enumerate(term.args):
> ____mark_term(term.args[i])

It should read:

for i,help in enumerate(term.args):
____mark_term(help)

But then i isn't need.

Mostowski Collapse schrieb am Mittwoch, 15. September 2021 um 20:22:50 UTC+2:
> Do you mean, replace this:
> i = 0
> while i < len(term.args) - 1:
> ____mark_term(term.args[i])
> ____i += 1
> term = term.args[i]
>
> By this:
>
> for i,term in enumerate(term.args):
> ____mark_term(term.args[i])
>
> This wouldn't be correct anymore. The
> recursive call is only for the arguments
> except for the last one one.
> alister schrieb am Mittwoch, 15. September 2021 um 20:17:23 UTC+2:
> > On Wed, 15 Sep 2021 18:23:10 +0200, 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?
> > >
> > > Julio Di Egidio wrote:
> > <sniped due to top posting>
> >
> > this is probably a string contender
> >
> > i = 0
> > while i < len(term.args) - 1:
> > mark_term(term.args[i])
> > i += 1
> > term = term.args[i]
> >
> > try replacing with something more pythonic
> >
> > for index,term in enumerate(term.args):
> > mark_term(term.args[i])
> >
> >
> > & possibly go all the way to changing it into a comprehension
> >
> > there are other similar anti patterns throughout this code.
> >
> > any time you are manually keeping a counter as an index into a list,tupple
> > other iterable YOU ARE DOING IT WRONG!
> >
> > Do not write javascript in python, write python
> >
> >
> >
> > --
> > Two percent of zero is almost nothing.
> >
> >
> >
> >
> > --
> > Whoever dies with the most toys wins.
--
https://mail.python.org/mailman/listinfo/python-list

On Wed, 15 Sep 2021 11:31:48 -0700, Mostowski Collapse wrote:

> There is a further problem with this:
>
>> for i,term in enumerate(term.args):
>> ____mark_term(term.args[i])
>
> It should read:
>
> for i,help in enumerate(term.args):
> ____mark_term(help)
>
> But then i isn't need.
even Better (i had only skimmed the code as I was certain I would find
this, it is probably the No. 1 thing new python programmers get wrong
if your example is correct the it can be simplified even further to

for help in term.args:
mark_term(help)

& if help does not get used after this loop then a comprehension is even
better
_ == [mark_term(help) for help in term.args]


the underscore character is python convention for an unneeded place-
holder variable.

>
> Mostowski Collapse schrieb am Mittwoch, 15. September 2021 um 20:22:50
> UTC+2:
>> Do you mean, replace this:
>> i = 0 while i < len(term.args) - 1:
>> ____mark_term(term.args[i])
>> ____i += 1 term = term.args[i]
>>
>> By this:
>>
>> for i,term in enumerate(term.args):
>> ____mark_term(term.args[i])
>>
>> This wouldn't be correct anymore. The recursive call is only for the
>> arguments except for the last one one.
>> alister schrieb am Mittwoch, 15. September 2021 um 20:17:23 UTC+2:
>> > On Wed, 15 Sep 2021 18:23:10 +0200, 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?
>> > >
>> > > Julio Di Egidio wrote:
>> > <sniped due to top posting>
>> >
>> > this is probably a string contender
>> >
>> > i = 0 while i < len(term.args) - 1:
>> > mark_term(term.args[i])
>> > i += 1 term = term.args[i]
>> >
>> > try replacing with something more pythonic
>> >
>> > for index,term in enumerate(term.args):
>> > mark_term(term.args[i])
>> >
>> >
>> > & possibly go all the way to changing it into a comprehension
>> >
>> > there are other similar anti patterns throughout this code.
>> >
>> > any time you are manually keeping a counter as an index into a
>> > list,tupple other iterable YOU ARE DOING IT WRONG!
>> >
>> > Do not write javascript in python, write python
>> >
>> >
>> >
>> > --
>> > Two percent of zero is almost nothing.
>> >
>> >
>> >
>> >
>> > --
>> > Whoever dies with the most toys wins.





--
Pie are not square. Pie are round. Cornbread are square.
--
https://mail.python.org/mailman/listinfo/python-list

On Wed, 15 Sep 2021 18:40:52 +0000, alister wrote:

> On Wed, 15 Sep 2021 11:31:48 -0700, Mostowski Collapse wrote:
>
>> There is a further problem with this:
>>
>>> for i,term in enumerate(term.args):
>>> ____mark_term(term.args[i])
>>
>> It should read:
>>
>> for i,help in enumerate(term.args):
>> ____mark_term(help)
>>
>> But then i isn't need.
> even Better (i had only skimmed the code as I was certain I would find
> this, it is probably the No. 1 thing new python programmers get wrong if
> your example is correct the it can be simplified even further to
>
> for help in term.args:
> mark_term(help)
>
> & if help does not get used after this loop then a comprehension is even
> better _ == [mark_term(help) for help in term.args]
>
>
> the underscore character is python convention for an unneeded place-
> holder variable.
>
>
I also notice you are using match case - this was only introduced in
python 10 so it is very new (i had not seen it before)
the break statements are probably not necessary as if ii understand this
feature correctly python does not fall-through & execute every subsequent
case after a successful match.

& finally the netiquette in this forum is to interleave of bottom post
rather than top post, it makes it easier to follow the thread.





--
Don't quit now, we might just as well lock the door and throw away the
key.
--
https://mail.python.org/mailman/listinfo/python-list

And how do you iterate over the first n-1 elements
of a list with n elements? This is what my code does:

i = 0
while i < len(term.args) - 1:
____mark_term(term.args[i])
____i += 1
term = term.args[i]

You can try yourself:

% python3
>>> foo = ["a", "b", "c"]
>>> i = 0
>>> while i < len(foo) - 1:
... print("mark_term", foo[i])
... i += 1
...
mark_term a
mark_term b
>>> foo = foo[i]
>>> foo
'c'

alister schrieb am Mittwoch, 15. September 2021 um 20:41:12 UTC+2:
> On Wed, 15 Sep 2021 11:31:48 -0700, Mostowski Collapse wrote:
>
> > There is a further problem with this:
> >
> >> for i,term in enumerate(term.args):
> >> ____mark_term(term.args[i])
> >
> > It should read:
> >
> > for i,help in enumerate(term.args):
> > ____mark_term(help)
> >
> > But then i isn't need.
> even Better (i had only skimmed the code as I was certain I would find
> this, it is probably the No. 1 thing new python programmers get wrong
> if your example is correct the it can be simplified even further to
>
> for help in term.args:
> mark_term(help)
>
> & if help does not get used after this loop then a comprehension is even
> better
> _ == [mark_term(help) for help in term.args]
>
>
> the underscore character is python convention for an unneeded place-
> holder variable.
> >
> > Mostowski Collapse schrieb am Mittwoch, 15. September 2021 um 20:22:50
> > UTC+2:
> >> Do you mean, replace this:
> >> i = 0 while i < len(term.args) - 1:
> >> ____mark_term(term.args[i])
> >> ____i += 1 term = term.args[i]
> >>
> >> By this:
> >>
> >> for i,term in enumerate(term.args):
> >> ____mark_term(term.args[i])
> >>
> >> This wouldn't be correct anymore. The recursive call is only for the
> >> arguments except for the last one one.
> >> alister schrieb am Mittwoch, 15. September 2021 um 20:17:23 UTC+2:
> >> > On Wed, 15 Sep 2021 18:23:10 +0200, 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?
> >> > >
> >> > > Julio Di Egidio wrote:
> >> > <sniped due to top posting>
> >> >
> >> > this is probably a string contender
> >> >
> >> > i = 0 while i < len(term.args) - 1:
> >> > mark_term(term.args[i])
> >> > i += 1 term = term.args[i]
> >> >
> >> > try replacing with something more pythonic
> >> >
> >> > for index,term in enumerate(term.args):
> >> > mark_term(term.args[i])
> >> >
> >> >
> >> > & possibly go all the way to changing it into a comprehension
> >> >
> >> > there are other similar anti patterns throughout this code.
> >> >
> >> > any time you are manually keeping a counter as an index into a
> >> > list,tupple other iterable YOU ARE DOING IT WRONG!
> >> >
> >> > Do not write javascript in python, write python
> >> >
> >> >
> >> >
> >> > --
> >> > Two percent of zero is almost nothing.
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Whoever dies with the most toys wins.
> --
> Pie are not square. Pie are round. Cornbread are square.
--
https://mail.python.org/mailman/listinfo/python-list