Mailing List Archive

There is a Python 3.8 compatible version here:

https://github.com/jburse/dogelog-moon/blob/main/devel/runtimepy/machine2.py

I have replaced match by if-then-else. So as to
be able to test with GraalVM. GraalVM is still faster
despite using if-then-else.

But GraalVM needs some time to JIT the code.
You need to make some cold runs before you
see kicking it being fast.

Mostowski Collapse schrieb am Mittwoch, 15. September 2021 um 20:48:31 UTC+2:
> 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

What could be slow, repeatedly requesting the "args"
field. Maybe I should do:

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

Mostowski Collapse schrieb am Mittwoch, 15. September 2021 um 20:48:31 UTC+2:
> 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

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

> 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:

use a slice
as a generic example you can try in the interactive interpreter (aka
REPL):

>>>items = [1,2,3,4,5,6,7,8,9,0]
>>>for item in items[:-1]:
>>> print(item)

1
2
3
4
5
6
7
8
9

I should state for the record that I am no Python expert, I mainly visit
this news group to learn.
sometimes from reading solutions & somtimes by trying to work out what
the solution might be.

most productively by working out a solution & seeing if other posters
agree (& working out why they don't)



--
The universe seems neither benign nor hostile, merely indifferent.
-- Sagan
--
https://mail.python.org/mailman/listinfo/python-list

On Thu, Sep 16, 2021 at 5:15 AM Mostowski Collapse <bursejan@gmail.com> wrote:
>
> 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.
>

No, you're thinking in terms of microoptimizations. Exception handling
isn't THAT slow. I'm talking more about how everything's getting
packaged up and then unpackaged (the repeated use of the "Compound"
class looks highly suboptimal), rather than reworking your algorithm
to behave more cleanly.

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

On Wed, 15 Sep 2021 11:56:47 -0700, Mostowski Collapse wrote:

> What could be slow, repeatedly requesting the "args"
> field. Maybe I should do:
>
> help = term.args i = 0 while i < len(help) - 1:
> ____mark_term(help[i])
> ____i += 1 term = help[i]
>
No this construct is a common error in new python programmers
the next progression they make is when they discover the range function
items = [1, 2, 3, 4, 5, 6, 7, 8, 9, 0]
for x in range(len(list)):
print (items[x])

but that is equally inefficient

the pythonic way is as previously suggested

for item in items:
print(item)

then the management of the index is being handled by the python
interpreter internally & is effectively machine code.
every time you increment your own pointer the interpreter has to process
reading the next line, reading the variable , incrementing it & then
using it. this is what makes your current code slow.


if you ever find your self creating a variable purely to use as a pointer
into a list then you are almost certainly taking the wrong approach.

more usefull links
https://www.youtube.com/watch?v=zdJEYhA2AZQ






--
"Show me a good loser, and I'll show you a loser."
-- Vince Lombardi, football coach
--
https://mail.python.org/mailman/listinfo/python-list

And how do you only iterate over n-1 elements?
I don't need a loop over all elements.

With array slicing?

Someting like:

for item in items[0:len(items)-2]:
___print(item)

Or with negative slicing indexes? Problem
is my length can be equal to one.

And when I have length equal to one, the
slice might not do the right thing?

LoL

alister schrieb am Mittwoch, 15. September 2021 um 22:00:30 UTC+2:
> for item in items:
> print(item)

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

Ok you suggested:

>>>items = [1,2,3,4,5,6,7,8,9,0]
>>>for item in items[:-1]:
>>> print(item)

1
2
3
4
5
6
7
8
9

Does this also work for length = 1? Ok let me try:

>>> foo = ["a","b","c"]
>>> for x in foo[:-1]:
... print(x)
...
a
b
>>> foo = ["a"]
>>> for x in foo[:-1]:
... print(x)
...

Oki Doki

Mostowski Collapse schrieb am Mittwoch, 15. September 2021 um 23:10:50 UTC+2:
> And how do you only iterate over n-1 elements?
> I don't need a loop over all elements.
>
> With array slicing?
>
> Someting like:
>
> for item in items[0:len(items)-2]:
> ___print(item)
>
> Or with negative slicing indexes? Problem
> is my length can be equal to one.
>
> And when I have length equal to one, the
> slice might not do the right thing?
>
> LoL
> alister schrieb am Mittwoch, 15. September 2021 um 22:00:30 UTC+2:
> > for item in items:
> > print(item)
--
https://mail.python.org/mailman/listinfo/python-list

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

BTW: I could already make it faster, by not repeatedly
accessing .arg anymore. It went down from ca.:

171'000 ms

To this here:

140'000 ms

But only in the cold run. In the warm run it went back
to 171'000 ms. Possibly when my code is faster,
it will create objects more faster, and kill the Python GC.

Or it was because my Laptop went into screen black?
And throttled the CPU. Not sure.

Mostowski Collapse schrieb am Mittwoch, 15. September 2021 um 23:13:12 UTC+2:
> Ok you suggested:
> >>>items = [1,2,3,4,5,6,7,8,9,0]
> >>>for item in items[:-1]:
> >>> print(item)
>
> 1
> 2
> 3
> 4
> 5
> 6
> 7
> 8
> 9
> Does this also work for length = 1? Ok let me try:
> >>> foo = ["a","b","c"]
> >>> for x in foo[:-1]:
> ... print(x)
> ...
> a
> b
> >>> foo = ["a"]
> >>> for x in foo[:-1]:
> ... print(x)
> ...
>
> Oki Doki
> Mostowski Collapse schrieb am Mittwoch, 15. September 2021 um 23:10:50 UTC+2:
> > And how do you only iterate over n-1 elements?
> > I don't need a loop over all elements.
> >
> > With array slicing?
> >
> > Someting like:
> >
> > for item in items[0:len(items)-2]:
> > ___print(item)
> >
> > Or with negative slicing indexes? Problem
> > is my length can be equal to one.
> >
> > And when I have length equal to one, the
> > slice might not do the right thing?
> >
> > LoL
> > alister schrieb am Mittwoch, 15. September 2021 um 22:00:30 UTC+2:
> > > for item in items:
> > > print(item)
--
https://mail.python.org/mailman/listinfo/python-list

On 9/15/2021 5:10 PM, Mostowski Collapse wrote:
> And how do you only iterate over n-1 elements?
> I don't need a loop over all elements.
>
> With array slicing?
>
> Someting like:
>
> for item in items[0:len(items)-2]:
> ___print(item)
>
> Or with negative slicing indexes? Problem
> is my length can be equal to one.
>
> And when I have length equal to one, the
> slice might not do the right thing?
>
> LoL


From the python command prompt:

items = [1,2,3,4]

for itm in items:
print(itm)
1
2
3
4

for itm in items[:-2]:
print(itm)
1
2


for itm in items[:-3]:
print(itm)
1


for itm in items[:-4]:
print(itm)
(no result, no error thrown)


for itm in items[:-5]:
print(itm)
(no result, no error thrown)
--
https://mail.python.org/mailman/listinfo/python-list

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

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

On Thu, Sep 16, 2021 at 7:59 AM Mostowski Collapse <bursejan@gmail.com> wrote:
>
> BTW: I could already make it faster, by not repeatedly
> accessing .arg anymore. It went down from ca.:
>
> 171'000 ms
>
> To this here:
>
> 140'000 ms
>
> But only in the cold run. In the warm run it went back
> to 171'000 ms. Possibly when my code is faster,
> it will create objects more faster, and kill the Python GC.
>
> Or it was because my Laptop went into screen black?
> And throttled the CPU. Not sure.
>

Instead of worrying about all these details, start by simplifying your
code. Focus on clean, simple, readable code, and don't microoptimize.
Specifically, focus on the core arithmetic that you're trying to do,
and get rid of all the bookkeeping overhead; most of that is a waste
of time. I mentioned earlier the repeated boxing and unboxing in
"Compound" objects - have you changed anything with those?

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

Compound is not used for boxing. Integers and floats
are represented directly. Also integers are not mapped to
floats. But maybe compound could be a little flattened,

like using directly an array. But then you cannot assure
anymore "clean, simple, readable code". For example now
I have clean, simple and readable code, since I can

access the functor of a compound via:

obj.functor

but when I flatten Compound into arrays, it would become:

obj[0]

Should I declare a constant FUNCTOR = 0? Some of your
requirements have a trade-off, not all of them can be
sustained simultaneously so easy.

I am rather expecting languages like Python and JavaScript
to offer the same comfort as C or Java, except that
I don't need to write types for all the varianbles and fields

all the time. But this requires smart language compiler
and language runtime. V8 Chrome has interesting articles
how they optimize access like .functor.

Chris Angelico schrieb am Donnerstag, 16. September 2021 um 00:02:54 UTC+2:
> On Thu, Sep 16, 2021 at 7:59 AM Mostowski Collapse <burs...@gmail.com> wrote:
> >
> > BTW: I could already make it faster, by not repeatedly
> > accessing .arg anymore. It went down from ca.:
> >
> > 171'000 ms
> >
> > To this here:
> >
> > 140'000 ms
> >
> > But only in the cold run. In the warm run it went back
> > to 171'000 ms. Possibly when my code is faster,
> > it will create objects more faster, and kill the Python GC.
> >
> > Or it was because my Laptop went into screen black?
> > And throttled the CPU. Not sure.
> >
> Instead of worrying about all these details, start by simplifying your
> code. Focus on clean, simple, readable code, and don't microoptimize.
> Specifically, focus on the core arithmetic that you're trying to do,
> and get rid of all the bookkeeping overhead; most of that is a waste
> of time. I mentioned earlier the repeated boxing and unboxing in
> "Compound" objects - have you changed anything with those?
>
> ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

On Fri, Sep 17, 2021 at 3:20 AM Mostowski Collapse <bursejan@gmail.com> wrote:
>
> Compound is not used for boxing. Integers and floats
> are represented directly. Also integers are not mapped to
> floats. But maybe compound could be a little flattened,
>

"Boxing" in this case isn't about ints and floats, since Java-like
bizarrenesses simply don't happen in Python; I'm talking about the way
that you frequently build up a Compound object for various situations
(even for throwing an error - you have a function that constructs a
generic Exception, and then buries a Compound inside it), and then
you're frequently checking if something is an instance of Compound.
All these constant back-and-forths are extremely expensive, since
they're not part of your algorithm at all.

At very least, use tuples instead of Compounds, but it would be far
better to ask less questions about your data and do more things by
tidying up your algorithm. Unfortunately, I can't really advise with
any detail, because you have code like this:

###
# Mark a term.
#
# @param term The term.
##
def mark_term(term):

What does that even mean?! I get it, you have a term, and you're
marking it. Whatever that mark means. The comments add absolutely
nothing that the function header didn't tell me. Are you implementing
your own garbage collection on top of Python's? Or something else?
It's extremely hard to give any sort of recommendations when your code
is hard to read, and nearly all of the comments are nothing more than
restating what can be seen in the next line of code. Also, with the
number of globals you're using, tracing the purpose of your functions
is not easy.

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

About Exceptions: Thats just building ISO core
standard Prolog error terms.

About Garbage Collection: Thats just Prolog
garbage collection, which does shrink some
single linked lists, which ordinary
programmig language GC cannot do,

or maybe some Weak Pointer magic can do it?
The use case is very simple. A Prolog system
has a so called trail. The trail in Dogelog
Runtime is a single linked list:

-->[ A ]-->[ B ]-->[ C ]-->

Now if B becomes unused, you need to rewire
the trail, it should then look like:

-->[ A ]---------->[ C ]-->


If a programming language has a means to
communicate this to the Garbage Collector,
I happy to apply it. The challenge is many
fold, the pointer from A to B for example

needs not to be accounted to determine
whether B is reachable. So all the links
in the trail are weak pointers. But they
are weak pointers that need to

be able to adapt.

Chris Angelico wrote:
> On Fri, Sep 17, 2021 at 3:20 AM Mostowski Collapse <bursejan@gmail.com> wrote:
>>
>> Compound is not used for boxing. Integers and floats
>> are represented directly. Also integers are not mapped to
>> floats. But maybe compound could be a little flattened,
>>
>
> "Boxing" in this case isn't about ints and floats, since Java-like
> bizarrenesses simply don't happen in Python; I'm talking about the way
> that you frequently build up a Compound object for various situations
> (even for throwing an error - you have a function that constructs a
> generic Exception, and then buries a Compound inside it), and then
> you're frequently checking if something is an instance of Compound.
> All these constant back-and-forths are extremely expensive, since
> they're not part of your algorithm at all.
>
> At very least, use tuples instead of Compounds, but it would be far
> better to ask less questions about your data and do more things by
> tidying up your algorithm. Unfortunately, I can't really advise with
> any detail, because you have code like this:
>
> ###
> # Mark a term.
> #
> # @param term The term.
> ##
> def mark_term(term):
>
> What does that even mean?! I get it, you have a term, and you're
> marking it. Whatever that mark means. The comments add absolutely
> nothing that the function header didn't tell me. Are you implementing
> your own garbage collection on top of Python's? Or something else?
> It's extremely hard to give any sort of recommendations when your code
> is hard to read, and nearly all of the comments are nothing more than
> restating what can be seen in the next line of code. Also, with the
> number of globals you're using, tracing the purpose of your functions
> is not easy.
>
> ChrisA
>

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

Here is a challenge for Python.
Can Python solve Sudoku?

Mostowski Collapse wrote:
> 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

A friend just sent me a Web Sudoku made with Dogelog Runtime
https://gist.github.com/jburse/c85297e97091caf22d306dd8c8be12fe#gistcomment-3895696

LoL

Mostowski Collapse schrieb am Donnerstag, 16. September 2021 um 21:59:05 UTC+2:
> Here is a challenge for Python.
> Can Python solve Sudoku?
>
> Mostowski Collapse wrote:
> > 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

Some questions make no sense to me.

Can a kind of snake solve Sudoku? Do you mean a specific puzzle, or any puzzle or even a puzzle with no solution?

Can a programming language do it? Well, in my experience, programming languages are tools to be used by humans, or sometimes by other programming languages. They are not sentient and cannot be asked to solve much of anything.

So is the question whether someone can program using only Python to solve an arbitrary sudoku problem? Short answer is you can do that in just about ANY language. I mean by brute force, if you have a 9 by 9 matrix with some of the 81 locations already filled in, then you can try every darn combination of the other spots using digits 1 to 9 and then ignore any where the rows and columns and the 9 3x3 submatrices do not follow the rules. At least one solution is guaranteed to pop out if there is one. Sure, such methods may run out of memory or take a while, but many can use little memory and some can speed things up by not going down blind alleys such as placing a number in a position where there already is the same number on the same row or column or sub-matrix.

So is the real question whether a human has already made a decent implementation in Python available? Sure, do a little searching and there are plenty of such things including some that use interesting features of python and some that are just translations from a more primitive language.



-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On Behalf Of Mostowski Collapse
Sent: Thursday, September 16, 2021 3:59 PM
To: python-list@python.org
Subject: Re: ANN: Dogelog Runtime, Prolog to the Moon (2021)

Here is a challenge for Python.
Can Python solve Sudoku?

Mostowski Collapse wrote:
> 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

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

The new release 0.9.6 is quite speedy:

"Maailman vaikein"
850002400720000009004000000000107002305000900040000000000080070017000000000036040
time(solve(Puzzle))
% Wall 41354 ms, gc 520 ms, 3143029 lips
in Browser

See also:

Preview: New para/1 instruction for Dogelog runtime. (Jekejeke)
https://twitter.com/dogelogch/status/1438586282502983682

Preview: New para/1 instruction for Dogelog runtime. (Jekejeke)
https://www.facebook.com/groups/dogelog

Avi Gross schrieb am Donnerstag, 16. September 2021 um 23:43:10 UTC+2:
> Some questions make no sense to me.
>
> Can a kind of snake solve Sudoku? Do you mean a specific puzzle, or any puzzle or even a puzzle with no solution?
>
> Can a programming language do it? Well, in my experience, programming languages are tools to be used by humans, or sometimes by other programming languages. They are not sentient and cannot be asked to solve much of anything.
>
> So is the question whether someone can program using only Python to solve an arbitrary sudoku problem? Short answer is you can do that in just about ANY language. I mean by brute force, if you have a 9 by 9 matrix with some of the 81 locations already filled in, then you can try every darn combination of the other spots using digits 1 to 9 and then ignore any where the rows and columns and the 9 3x3 submatrices do not follow the rules. At least one solution is guaranteed to pop out if there is one. Sure, such methods may run out of memory or take a while, but many can use little memory and some can speed things up by not going down blind alleys such as placing a number in a position where there already is the same number on the same row or column or sub-matrix.
>
> So is the real question whether a human has already made a decent implementation in Python available? Sure, do a little searching and there are plenty of such things including some that use interesting features of python and some that are just translations from a more primitive language.
> -----Original Message-----
> From: Python-list <python-list-bounces+avigross=veriz...@python.org> On Behalf Of Mostowski Collapse
> Sent: Thursday, September 16, 2021 3:59 PM
> To: pytho...@python.org
> Subject: Re: ANN: Dogelog Runtime, Prolog to the Moon (2021)
>
> Here is a challenge for Python.
> Can Python solve Sudoku?
>
> Mostowski Collapse wrote:
> > 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
--
https://mail.python.org/mailman/listinfo/python-list

On 16/09/21 4:23 am, Mostowski Collapse wrote:
> I really wonder why my Python implementation
> is a factor 40 slower than my JavaScript implementation.

There are Javascript implementations around nowadays that are
blazingly fast. Partly that's because a lot of effort has been
put into them, but it's also because Javascript is a different
language. There are many dynamic aspects to Python that make
fast implementations difficult.

> I use in Python:
>
>   temp = [NotImplemented] * code[pos]
>   pos += 1
>
> is the the idiom [_] * _ slow?

No, on the contrary it's probably the fastest way to do it
in Python. You could improve it a bit by precomputing
[NotImplemented]:

# once at the module level
NotImplementedList = [NotImplemented]

# whenever you want a new list
temp = NotImplementedList * code[pos]

That's probably at least as fast as built-in function for
creating lists would be.

> does it really first create an
> array of size 1 and then enlarge it?

It does:

>>> def f(code, pos):
... return [NotImplemented] * code[pos]
...
>>> from dis import dis
>>> dis(f)
2 0 LOAD_GLOBAL 0 (NotImplemented)
2 BUILD_LIST 1
4 LOAD_FAST 0 (code)
6 LOAD_FAST 1 (pos)
8 BINARY_SUBSCR
10 BINARY_MULTIPLY
12 RETURN_VALUE

BTW, the Python terminology is "list", not "array".
(There *is* something in the stdlib called an array, but
it's rarely used or needed.)

--
Greg

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

On Fri, Sep 17, 2021 at 7:17 AM Mostowski Collapse <janburse@fastmail.fm> wrote:
>
> About Exceptions: Thats just building ISO core
> standard Prolog error terms.
>
> About Garbage Collection: Thats just Prolog
> garbage collection, which does shrink some
> single linked lists, which ordinary
> programmig language GC cannot do,
>

Okay, so.... you're building your own garbage collection on top of
Python's, and you're wondering why it's slow?

Change your code to not try to implement one language inside another,
and you'll see a massive performance improvement.

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

On 16/09/21 2:56 pm, Mostowski Collapse wrote:
> I can access the functor of a compound via:
>
> obj.functor
>
> but when I flatten Compound into arrays, it would become:
>
> obj[0]
>
> Should I declare a constant FUNCTOR = 0?

You could, but keep in mind that access to a global in Python
is somewhat expensive, since it requires a dictionary lookup.

There's always a tradeoff between clarity and efficiency.
In this case, I think obj[0] is clear enough -- the reader
will be well aware that the first item of a term is the
functor. Especially if you use a name that makes it clear
what kind of object it is, rather than a generic name such
as "obj".

--
Greg

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

On 16/09/21 6:56 am, Mostowski Collapse wrote:
> What could be slow, repeatedly requesting the "args"
> field. Maybe I should do:
>
> help = term.args
> i = 0
> while i < len(help) - 1:
> ____mark_term(help[i])
> ____i += 1
> term = help[i]

Yes, that will certainly help.

But you're still evaluating len(help) - 1 every time around
the loop, so this is even better:

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

Some general principles to be aware of:

* Almost nothing is free -- Python very literally does what
you tell it to do, even if it looks dumb.

* Access to attributes and global variables is expensive
(requires at least one dict lookup, often more in the case
of attributes).

* Access to *local* variables, on the other hand, is very
cheap (essentially an array lookup).

* Function calls are expensive -- both to look up the name, if
it's global, which it usually is, and the machinery of the
call itself.

* Creating objects is expensive. Creating instances of
user-defined objects is more expensive than built-in ones.

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

Thanks for your response, will have a look.
Ok, dis() is all that is need to disassemble.

Very cool!

A long term goal could be indeed to have
a Prolog interpreter produce 20MLips, like
SWI-Prolog, but tightly integrated into

Python. So that it directly makes use of
the Python objects and the Python garbage
collection like Dogelog Runtime.

Although Dogelog Runtime has its own
garbage collection, its only used to help
the native Python garbage collection.

The result is that you can enjoy bi-directly
calling Python. For example the Prolog
adding of two numbers is realized as:

###
# +(A, B, C): [ISO 9.1.7]
# The predicate succeeds in C with the sum of A and B.
##
def eval_add(alpha, beta):
check_number(alpha)
check_number(beta)
try:
return alpha + beta
except OverflowError:
raise make_error(Compound("evaluation_error", ["float_overflow"]))

And then register it:

add("+", 3, make_dispatch(eval_add, MASK_MACH_FUNC))

Could also map the exception to a Prolog term later.
Thats not so much an issue for speed. The sunshine
case is straight forward.

But I might try dis() on eval_add(). Are exceptions
blocks in Python cheap or expensive? Are they like
in Java, some code annotation, or like in Go

programming language pushing some panic handler?

Greg Ewing schrieb:
> On 16/09/21 4:23 am, Mostowski Collapse wrote:
>> I really wonder why my Python implementation
>> is a factor 40 slower than my JavaScript implementation.
>
> There are Javascript implementations around nowadays that are
> blazingly fast. Partly that's because a lot of effort has been
> put into them, but it's also because Javascript is a different
> language. There are many dynamic aspects to Python that make
> fast implementations difficult.
>
>> I use in Python:
>>
>>    temp = [NotImplemented] * code[pos]
>>    pos += 1
>>
>> is the the idiom [_] * _ slow?
>
> No, on the contrary it's probably the fastest way to do it
> in Python. You could improve it a bit by precomputing
> [NotImplemented]:
>
> # once at the module level
> NotImplementedList = [NotImplemented]
>
> # whenever you want a new list
> temp = NotImplementedList * code[pos]
>
> That's probably at least as fast as built-in function for
> creating lists would be.
>
>> does it really first create an
>> array of size 1 and then enlarge it?
>
> It does:
>
> >>> def f(code, pos):
> ...  return [NotImplemented] * code[pos]
> ...
> >>> from dis import dis
> >>> dis(f)
>   2           0 LOAD_GLOBAL              0 (NotImplemented)
>               2 BUILD_LIST               1
>               4 LOAD_FAST                0 (code)
>               6 LOAD_FAST                1 (pos)
>               8 BINARY_SUBSCR
>              10 BINARY_MULTIPLY
>              12 RETURN_VALUE
>
> BTW, the Python terminology is "list", not "array".
> (There *is* something in the stdlib called an array, but
> it's rarely used or needed.)
>

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