Re: LispM Market Share

[Richard Lamson <rsl%max-fleischer.ila-sf.dialnet.symbolics.com@RELAY.CS.NET>]

    Date: Tue, 16 Jan 90 12:00 EST
    From: barmar@Think.COM (Barry Margolin)

	Date: Tue, 16 Jan 90 10:21:28 -0500
	From: kanderso@DINO.BBN.COM

	?  Why is LISPM I/O is slow?

    The explanation I've been given is that it's the software.  I think
    Genera would be a very good piece of ammunition for those computer
    scientists who argue that modularity reduces performance.  They've done
    a very good job of separating the components of the system into layers,
    and rarely cross layers.  This is what has allowed the system to evolve
    as well as it has.  The extensive use of Flavors probably hurts the
    performance a bit, too, although it has gotten much better over the
    years.  Text I/O tends to be slowed down due to the time spent
    converting between ASCII and the Lispm character set.

Are we talking about the same system?  Genera hardly ever converts between
ASCII and Lispm character set except when transmitting data over "foreign"
protocols (e.g., SMTP, FTP, NFS).

Although the author did not say so (the mail to which he was replying
essentially did), I believe the original complaint is about LMFS, which
certainly does not convert to/from ASCII.  LMFS is a performance dog.  Data
transfer rates and file lookup rates are both inadequate in LMFS.  This has
mostly to do with the strategies used by LMFS in its choice of data layout,
and a little to do with the LMFS locking strategy (if you have more than one
LMFS user at a time).  The true problem with LMFS is how much disk I/O it has
to do for a file lookup, and how poorly it optimizes the use of the disk when
reading a file.  The use of Flavors contributes, I would guess, less than 10%
to the poor performance of LMFS (just a guess, of course; I haven't metered
it and can't even propose a strategy for doing so).

Part of the problem in LMFS is (or at least used to be) the poor performance
of the Lispm disk driver.  Ken Olum did some studies a couple of years ago
and discovered that even attempting to read three or four contiguous blocks
in a row on an Eagle was a sure way to miss a complete revolution.  I imagine
that improving the disk driver would also improve paging performance, which
might make window selection, etc., speedier.  I do believe, however, that
some fundamental research about how to do paging better is still required;
the flush-the-least-recently-used-page algorithm is probably not correct when
you change activities and really want to, say, flush ALL of your Zmail (data,
anyway) pages when you select Concordia.

The second complaint is almost certainly about the speed of network data
transfer.  Symbolics has done a lot in this area for 7.4/8.0, so, for
example, TCP and UDP packets are no longer limited by the small Ethernet
packet limit.  I understand data transfer rates approximately 0.5-0.6 of
those of Unix-based NFS servers have been observed (as opposed to 0.05-0.1).
This again was a problem with poor data design.

Genera does not prevent poor software design.  It enables good design and
sometimes good testing.