lispm market share; slow LISPM I/O

["Leslie A. Walko" <attila@FLASH.BELLCORE.COM>]

>From:  barmar@think.com (Barry Margolin)
>Newsgroups:     BCR.DIGEST.SLUG
>Message-ID:  <19015@bellcore.bellcore.com>

> 
> 
> 
>     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.
> 
>                                                 barmar
> 
 
I was under the impression that file I/O slow because there is no
overlapped I/O implemented in Genera --process waits while disk seeks.
The official justification for this is that the user waits anyways since
these are single user workstations.  The technical reasons I heard were
that since I/O is implemented in microcode --there is no dedicated
chanel processor hardware-- the i/o task keeps the processor quite busy.

The blocking and de-blocking of the data comming off the disk is rather
cpu intensive also, so the net result (controlling rather unintelligent
ESDI disk + blocking + error checking + some lmfs to raw file mapping
overhead) is high CPU utilization.  

One of my collegues (Peter Clitherow) has done some lmfs data transfer
rate measurements, and the numbers are rather horrible.  This leads me
to beleive that a dedicated channel controller would be a good thing.
It allow for the efficient implementation for overlapped I/O becasue it
would take over all the CPU load currently associated with an I/O.  The
buffer pool under the channel controller's supervision could also do
extensive pre-fetching, pre-reading of pages, thus greatly improving
sequental file read/write performance.  Curiously, the dedicated
processor would not do much for paging, but a big buffer pool would sure
help.

So how about some lower memory board prices!!!!

Leslie Walko