Oppolzer - Informatik / Blog

Blog-Hauptseite      Neuester Artikel      Älterer Artikel      Neuerer Artikel      Älterer gleiche Kategorie      Neuerer gleiche Kategorie

IBM-MAIN - Neue Interpretersprache Lua ist schneller als REXX (auf z/OS)


Re: [ANN] Lua4z: the Lua programming language on z/OS, with batteries


Bernd Oppolzer <bernd.oppolzer@T-ONLINE.DE>


IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>


2014.10.24 10:46:04

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


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

Blog-Hauptseite      Neuester Artikel      Älterer Artikel      Neuerer Artikel      Älterer gleiche Kategorie      Neuerer gleiche Kategorie