On Sat, 12 Feb 1994 18:11:57 -0500 "Craig A. Summerhill" <[log in to unmask]>
said:
I don't know why I'm answering this, but anyway...
>Making comparisons of Unix-Listprocessor performance from one machine to
>the next is difficult, comparing it to the largely VM/NJE/RSCS LISTSERV
>is nuts.
While I would probably agree with you if people were comparing numbers
that differed by about 20-30%, I think you're not realizing that the
order of magnitude is different. It is fair to say that, in general, a
unix list manager running on a typical unix workstation has a lot more
CPU power at its disposal than LISTSERV running on a typical BITNET
system. To take an extreme example, LISTSERV@SEARN deals out 40,000
messages a day to researchers in Sweden. The CPU on which it runs has
about 50% of the horsepower of a 486/66 to start with (and that's with
the 486 doing 32-bit arithmetic in 16-bit DOS mode), 14M of memory, and
one disk unit with about the same performance as a typical SCSI-2
workstation disk. The PC I am typing this from has more hardware
resources, except the disk is smaller. In this environment LISTSERV uses
up 1.52% of the CPU (over 720h), and all the SMTP processes and anything
that sendmail might possibly do under unix is about 6%, counting traffic
that has nothing to do with LISTSERV. Finally, a sizeable fraction of the
code is written in an interpreted language; this more than offsets
whatever little assembler code is left (mostly the assembler code does
things one cannot do in REXX). And on top of that, the PASCAL compiler is
probably the most inefficient IBM has. The person who wrote the code
generator does not understand the architecture. Slower instructions are
used to implement FOR loops in order to save two bytes for the constant
'1' (that is two bytes for the entire routine, not even two bytes per
loop). When you take the address of something, the compiler adds an
instructions to clear a bit that is architecturally always cleared. I
assume the author of the compiler was not sure and thought "better safe
than sorry". There are been no new version since 1988, in spite of the
fact that many IBM products are written in that language. At any rate
there is easily a factor of two compared to just about any other IBM
compiler. So you will understand that I am beginning to get tired of
hearing that "LISTSERV is faster because it is highly optimized for the
S/370 architecture and runs on very fast mainframes".
>Finally, the Unix-Listprocessor is heavily reliant on SMTP (primarily
>unix's sendmail) for the actual delivery of mail. With all deference to
>the IETF powers-that-be, this is a protocol which is not particularly
>good a point to multi-point transmission
I agree, but what do you think LISTSERV uses to deliver mail to Internet
users? RSCS? :-)
>However, if Mr. Thomas plans on relying on sendmail for the actual
>spooling and delivery of mail, as the Unix-Listprocessor system does, he
>may find that his own product doesn't perform as well as it does in its
>current environment.
I am aware of this problem. The first versions will use sendmail (or
whatever is installed on the box), for the simple reason that people
would rather have a slower product in a year than wait an extra year just
for speed. The architecture of LISTSERV makes it possible to have the
actual delivery done on another system with more suitable software (in
practice this means an AXP workstation running VMS), so technically
speaking the problem can be solved by an administrative change. However I
expect that this will not help as most people will want a unix-only
solution and the only way to improve the performance of sendmail is to
replace it by something else that has to be coded.
>you'll have a hard time convincing me that Mr. Thomas has better
>solutions to some of the real problems confronting list-management
>developers in unix-like environments than those employed in
>Unix-Listprocessor.
Here again I agree with you. The philosophy of LISTSERV is that the user
(and this includes list owners) should not have to know what operating
system it is running under, least of all have to learn this operating
system. If you think list management in a unix-like environment should be
different from list management in a VM-like environment, you will
probably not like LISTSERV. The VM version does not require or allow the
user or list owner to make use of VM features such as pipelines, REXX,
etc. The unix version will behave the same way: the syntax of all but a
few commands and control files will be the same, quoting will be
accomplished with " rather than \, there will be no ability to put awk
expressions in list header keywords, and so on.
>Personally speaking, the product will have to demonstrate some
>significant and *measurable* performance increase over the
>Unix-Listprocessor system before I will be persuaded to purchase a
>Pascal compiler in order to compile the system. Unless L-Soft can ship
>pre-compiled binaries,
We will definitely ship tested binaries.
Eric
|
