Background information: as you might have heard, the REXX compiler has
been recently added to the list of HESC programs, which basically means
that academic sites on the "right" side of a US customs office will soon
be able to get it free of charge. This in turn means most of BITNET may
soon have the REXX compiler available, and may want to compile LISTSERV
to save cycles. Unfortunately, a significant fraction of the 1.6e code
(in terms of number of EXEC files) is not compilable; since these
non-compilable EXEC's are the ones most frequently executed (LSVCMD,
LSVDIST2, LSVXMAIL, LSV822IN) and burning most of the CPU time LISTSERV
is using, there is very little to be expected from a compiled version of
1.6e.
Since this was not precisely satisfactory, I took steps to make most of
LISTSERV compilable in the next release. Unfortunately this means it will
be a bit slower when interpreted, but not considerably so. Anyway, the
potential savings for over 70% of the LISTSERV sites simply made it a
non-issue - it just had to be done.
So, I was waiting for the first LISTSERV sites to install the REXX
compiler when I noticed, yesterday, that CERNVM already has it. I do not
have a test LISTSERV account on that machine, so I could not make any
"real life" test, but I did compile a few EXEC's and run some benchmarks.
Since most of the LISTSERV code won't run outside the LISTSERV
environment, I substituted "standalone" EXEC's of mine with a similar
"profile" (read a file, do some processing, generate some terminal
output).
The results are, as I expected, very disappointing. The "purest" piece of
REXX in LISTSERV, LSV822IN (does not issue any CMS command and takes
around 1M instructions to complete) turned out to be a mere 3.4 times
faster when compiled. This in itself would not be so bad if it were not
by far the best improvement I have seen; most programs that do I/O (I/O
really means intensive EXECCOMM-ing in this context, this data is
acquired via LSVFILER, not EXECIO - the CPU time required for the actual
I/O is negligible) are around 2.5, some as low as 1.7. Since your average
backbone LISTSERV spends most of its time processing DISTRIBUTE jobs and
the compiler won't speed up disk or spool I/O, I think it would be unwise
to expect a CPU improvement in excess of a factor of 2.
Now, what is so bad about cutting the CPU bill in half? Well, apart from
the fact that this isn't the kind of performance one would expect from a
"compiler", there is a price to be paid for the 1.7 to 3.4 savings in CPU
time: the compiled code is around 4 times larger than the interpreted
version. This means you won't need 400k for the EXECLOADed "core", but
1.6M; I will let you draw your own conclusions as to the consequences
this will have on the working set of LISTSERV, and on the amount of disk
I/O generated when a non-EXECLOADed file is called.
It would be interesting to see whether the compiled version runs faster
(in terms of wall-clock time, notwithstanding the impact on the other
users) on a "small" machine with 16M of real memory or less and a
strained paging subsystem. I guess for such sites the best will be to
compile what really needs to be compiled, and leave the rest alone.
Eric
|
