And here an example of ooRexx being used without any direct access to Java:
d1=.datetime~new /* take time */
"java squares" /* run command */
d2=.datetime~new /* take time */
say "duration:" d2-d1
The results of running this program are:
G:\tmp\ibmmain\arrays>squares_oorexx.rex
100000000000000
duration: 00:00:00.247000
G:\tmp\ibmmain\arrays>squares_oorexx.rex
100000000000000
duration: 00:00:00.242000
Quite fast! ;)
---rony
On 11.01.2022 13:15, Rony G. Flatscher wrote:
> 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
