VMS vs. UNIX file system

[Chris Torek]

In article <3442 at crash.cts.com> jeh at crash.cts.com (Jamie Hanrahan) writes:
>How often do you need ISAM?  Well, if you have to implement it yourself,
>probably you'll do without.  But if it's there it gets used, for good and
>sufficient reasons.

This was Barry Shein's point.  But he might, and I will, go a bit
further:  sometimes it also gets used for bad, insufficient reasons.
(That does not mean it should not be there; but maybe it should not
be *too* easy to use.)

>... Some folks at BYU did a netnews workalike for VMS [using indexed
>files] ....  It's a VERY clean design, and they can process a batch of
>received news MUCH faster than Unix can running on the same hardware.
>(To be as exact as dim memory allows, I think they said ten times
>faster or so, and that the Unix folks at the site were both amazed
>and jealous.)

You are comparing incomparable things here.  The reason their news
unbacher is that much faster than the one in B news is almost certainly
because `it's a very clean design' and not because it uses any
particular storage format.  The B news unbatcher is a model of
inefficiency, clumsy patches, and re-re-re-re-worked code.  For
instance, an uncompressed batch file is read by forking a separate
process for each article in the file.  B news's only saving grace is
that it works, and it works on everything from PDP-11s to Convexes.

(Henry Spencer and Geoff Collyer rewrote the B news software and got
a similar order of magnitude performance increase, without changing
the file formats at all.)

>...  I offer this challenge:

Oh dear.

>Take a simple Unix filter like DETAB running on some Unix system on a
>VAX (Ultrix, BSD, AT&T, whatever).  Rewrite it to use record-oriented
>I/O under VMS.  Boot VMS on the same hardware (or the equivalent).
>We've done this and the VMS/RMS versions run *at least* twice as fast,
>sometimes five or six times.

If you pick your benchmarks carefully, you can prove anything.  Many
real programs spend a fair bit of time doing I/O, and VMS RMS I/O is
indeed quite efficient when properly used.  But so is Unix I/O.  VMS
currently has an implementation edge if the application reads large
blocks, since it does this by playing games with the MMU.  On the other
hand, Mach can do the same trick.

>I don't think that fixed vs.variable length records, implied
>carriage control, etc., are archaic at all.

I like the way Ken Thompson put it:

    These concepts fill a much-needed gap in other operating systems.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris