Looking again I see that a true J version would be faster:
* use A. to create the permutation
* use amend-in-place to do the modification
* append the # swaps to a list and handle the checksum at the end of
each loop
I also see that you used objects so the public names do not collide.
But locals are still better.
Henry rich
On 4/27/2022 12:26 PM, Jan-Pieter Jacobs wrote:
A while ago, Henry requested a comparison of interpreter speed.
For this purpose I translated the Fannkuch task from the Benchmark game
from Python to J as literally the same as possible (generators required a
huge cludge of locale based OOP and goto. statements).
Now that J has grown multi-threading capabilities, I completed the
translation, as the python code did also do multi-threading (actually it
seems to spin up multiple processes, rather than threads). The comparison
looks like this (on my modest laptop):
jpjacobs@icarus:~/Projects/J/BenchmarkGame$ time ~/j904/bin/jconsole
fannkuch-redux_nothread.ijs 10
73196
Pfannkuchen(10) = 38
real 1m35,353s
user 1m35,163s
sys 0m0,173s
jpjacobs@icarus:~/Projects/J/BenchmarkGame$ time ~/j904/bin/jconsole
fannkuch-redux_notasks.ijs 10
73196
Pfannkuchen(10) = 38
real 1m30,151s
user 1m30,008s
sys 0m0,138s
jpjacobs@icarus:~/Projects/J/BenchmarkGame$ time ~/j904/bin/jconsole
fannkuch-redux.ijs 10
73196
Pfannkuchen(10) = 38
real 1m2,029s
user 3m19,923s
sys 0m24,551s
jpjacobs@icarus:~/Projects/J/BenchmarkGame$ time python3.9
fannkuch-redux.py 10
73196
Pfannkuchen(10) = 38
real 0m6,753s
user 0m26,127s
sys 0m0,021s
The "nothread" version does not use threads at all; the "notasks" version
spins up the threads, but does not dispatch any tasks, in order to take a
look at perhaps the j engine using threads without explicit user
instruction. The version without underscores uses 4 tasks dispatched on 4
threads.
Summarising, it seems from the real time (actual time used) that creating
threads, but not using them slightly reduces the time taken to +-66%. Using
the treads to execute tasks does reduce the time taken further, but by far
not as low as 25%. This cannot be due to data communication overhead, since
each task receives 3 numbers, and returns 2. I also noticed some
inconsistent results in the parallel version, i.e. the program locking up,
or yielding a checksum that is not correct.
Python still beats J by an order of magnitude, and I suspect that it is due
to not having iterators, but having to emulate them using locales and
jumping around in the next__ functions with goto. . If anyone has a better
way of writing this, I'm curious.
I attached all 4 versions (3 J versions and 1 python version) of the task
to this message (remove the .txt extension before use).
Jan-Pieter
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
