On 11.01.2022 05:46, David Crayford wrote:
> On 10/1/22 11:15 pm, Seymour J Metz wrote:
>>> ooRexx will never be high speed because it's implementation is
>>> fundamentally ineffecient.
>> That seems to be begging the question. Certainly the current implementation
>> is inefficient, but
>> what fundamental issue prevents a more efficient implementation?
>
> A more effecient implementation requires a rewrite.
>
>> For that matter, what fundamental issue prevents compiling into Java
>> bytecode with a large
>> runtime similar to the CREXX runtime?
>
> None. TBH, I hadn't had much of a look at NetRexx but it's promising. It's
> strongly typed and the
> JVM is going to JIT compile it so it will be fast. As Rene mentioned you can
> use Java classes so
> there is a massive eco-system available.
BTW, you could use Java classes from ooRexx as well, hence there is a "massive
eco-system available"
for ooRexx. You would need the external function package named BSF4ooRexx,
which enables ooRexx to
work with any Java class library, no matter whether it got created with Java,
NetRexx, Kotlin,
Groovy, ...
> I knocked up some simple benchtests which create an array of squares and then
> find the maximum
> value. The maximum value is the end element. The results are just what I
> expected. ooRexx performs
> poorly.
Not a surprise. :)
This "simple benchtest" is architected in a way that makes interpreted
languages look especially bad
compared to compiled languages, it is of a form that is not relevant in real
life. Also, using
unnecessarily numeric 30 digits for the arithmetics is interesting, as well as
the outdated, seven
year old ooRexx 4.2 rather than ooRexx 5.0 does not help either.
> Stem variables are particularly bad which is to be expected because they are
> essentially
> associative arrays. Using the Array class was much better but the result was
> still many orders of
> magnitude worse then the
> other languages I tested. What's interesting is that LuaJIT is as fast as C++
> and interpreted Lua
> is almost as fast as Julia which has JIT.
Not a surprise. :)
Now, if it was truly the case that someone would need such an abmysal amount of
number crunching
then speed becomes interesting. In such a case what I would do for any
interpreted language, I would
use a compiled one.
As you point out the compiled versions (cpp, JIT-etc. compiled one) let the
interpreted languages
bite the dust. The question then would be whether to solve this particular
problem in an interpreted
language at all.
In the case of REXX-savvy programmers I would suggest to use NetRexx for this
particular purpose:
/* NetRexx: squares.nrx */
options binary /* in this case we want speed */
items = 10000000
s = long[items] /* define a Java array of type long */
loop i=1 to items
n=long i /* for multiplication we want to use long */
s[i-1] = n * n
end
/* use a Java stream (introduced with Java 8) */
say java.util.Arrays.stream(s).max.getAsLong
You would compile that NetRexx program with "netrexxc squares.nrx" and run the
resulting Java class
with "java squares".
To give you a feeling for the speed (you can test it right on your own computer
and compare with
your other versions), here the timings of your c++ program (compiled with MS
cl) and this NetRexx
program on my Windows 10 laptop (all in 32-bit mode):
* c++ (using MS compiler) out of the box:
G:\tmp\ibmmain\arrays>timeit squares.exe
*** ooRexx-Timeit: command: squares.exe
100000000000000
*** ended.
*** command: squares.exe
*** started: 2022-01-11T11:19:55.506000
*** ended: 2022-01-11T11:19:56.493000
**** duration: 00:00:00.987000*
* NetRexx (Java 17) out of the box:
G:\tmp\ibmmain\arrays>timeit java squares
*** ooRexx-Timeit: command: java squares
100000000000000
*** ended.
*** command: java squares
*** started: 2022-01-11T12:09:51.849000
*** ended: 2022-01-11T12:09:52.134000
**** duration: 00:00:00.285000*
As C++ on your machine was fastest of all compiled solutions, this may be quite
surprising: NetRexx
can beat even C++! :)
Again: pick the language that meets the job at hand at best! Doing abmysal
loopings, arrays, etc.
pick a compiled language, solving "bread-and-butter" problems use the language
that allows you to
quickly create the program solution in a readable, maintable manner.
REXX programmers have good reasons why they use an interpreter for their
problem solutions for
decades on mainframes.
And as can be seen, even such artificial samples constructed to make
interpreters look bad, it is
not difficult for programmers with REXX knowledge to use NetRexx to solve
problems that really would
need "hi speed".
Or with other words: whenever REXX programmers need functionality and speed on
a mainframe they
resort to external native programs that they instrumentate. The same is
possible with NetRexx in an
even easier manner!
---rony
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
