Now, if you want ooRexx to control an application and need to run the NetRexx
program from it, you
can do that with ooRexx (including timings) as such:
/* ooRexx solution to control execution of NetRexx' squares */
clz=bsf.loadClass("squares") /* load NetRexx' squares class */
/* create an empty Java array of type java.lang.String */
arr=bsf.createJavaArrayOf("java.lang.String")
d1=.dateTime~new /* take time */
/* run main method which expects a Java String array */
clz~main(arr)
d2=.dateTime~new /* take time */
say "duration:" d2-d1
::requires "BSF.CLS" /* get full access to Java */
The results of running this program are, believe it or not, even faster:
G:\tmp\ibmmain\arrays>rexx squares.rxj
100000000000000
duration: 00:00:00.095000
G:\tmp\ibmmain\arrays>rexx squares.rxj
100000000000000
duration: 00:00:00.109000
So the interpreted ooRexx can even beat ... :)
---rony
On 11.01.2022 12:21, Rony G. Flatscher wrote:
> 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
