Oppolzer - Informatik / Blog

Thank you very much.

Of course, it is all about the quality of the implementation. The implementation
on a certain environment may be bad or not very motivated ... but the language
REXX should not be blamed for this.

Some time ago (maybe 10 years) I tested REXX on OS/2 vs. Regina on Linux on the
very same hardware and discovered interesting differences; Regina was faster ...
I don't recall the numbers, but it was very significant. Same goes for file I/O
with C programs, again on the same hardware; IBM C compiler on OS/2 and gcc on
Linux. Very interesting differences, always in favor of Linux.

Unfortunately, I have no time to analyse Lua further, but I liked this
discussion very much.

Kind regards

Bernd


Am 24.10.2014 04:08, schrieb D.C.:
> On 24/10/2014 6:50 AM, Bernd Oppolzer wrote:
>> Doesn't the example in the benchmark show performance problems in EXECIO
>> instead of REXX? EXECIO, IMO, is not part of the REXX interpreter,
>> but instead
>> it is a vehicle (an external function) to do I/O from REXX on z/OS.
>> Other REXX implementations
>> (for example, on Linux or Windows) don't use EXECIO etc.; I/O there
>> is done with
>> native REXX functions.
>>
>
> I don't want to be too disparaging about REXX but I've profiled it
> extensively and it is not an effecient implementation. The variable
> access routines are where it spends a lot of time so any address
> SUBCOM interface is slow
> when compared to fast scripting languages.  Compiled REXX has a
> serious flaw in it's memory management. I profiled it using IBM APA
> and it appears to do a GETMAIN every time it wants a new stem varaible
> element.
> It could be dramatically improved just be using a better storage
> manager. I would want my money back if I paid for the REXX compiler.
>
>> So to be fair, the REXX interpreter functions should be compared with
>> Lua
>> interpreter functions, for example: some loop control or arithmetic.
>> Compiled languages like C will always outperform interpreted languages
>> in this area, so such comparisons are only of academic interest.
>>
>
> Lua is written in C and the majority of it's libraries are too. In
> some cases there is only 10% overhead for the Lua VM. I've got an SQL
> bench-test where Lua is not too far off C. And much easier to code and
> maintain.
>
> OK, let's try simple matrix multiplication which should test both
> array access and math.
>
> /* REXX */
> arg count
> if count = "" then count = 1000000
> start = sysvar("SYSCPU")
> do i = 1 to count
>   a.i = i * i
> end
> say 'CPU time = 'sysvar("SYSCPU") - start
>
> CPU time = 3.57
>
> local t = require("timer")()
> local count = arg[1]  or 1000000
> local a = {}
> for i = 1, count do a[i]  = a[i] * i end
> t:print_elapsed()
>
> elapsed time: 0.131965
>
>
> That's a huge difference, two orders of magnitude.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@listserv.ua.edu with the message: INFO IBM-MAIN