On 11.01.2022 14:06, David Crayford wrote:
> I've gone silent now Rony. But if you're a Windows user you may want to check
> out Measure-Command
> for PowerShell so you don't have to instrument your code with timers.
>
> [1]
> https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/measure-command?view=powershell-7.2
Thank you for this pointer, David!
Mostly I have been working on Windows, but also on Linux and MacOS, for making
sure that BSF4ooRexx
runs flawlessly and seamlessly on all those platforms.
---rony
>
> On 11/1/22 8:30 pm, Rony G. Flatscher wrote:
>> 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
