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