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 David Crayford:
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
