Xref: utzoo comp.os.vms:8751 comp.unix.wizards:11195 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!uwvax!oddjob!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.os.vms,comp.unix.wizards Subject: Re: VMS vs. UNIX file system Keywords: RMS, file system, stream files Message-ID: <13608@mimsy.UUCP> Date: 18 Sep 88 15:04:51 GMT References: <411@marob.MASA.COM> <178@arnold.UUCP> <3442@crash.cts.com> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 56 In article <3442@crash.cts.com> jeh@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@mimsy.umd.edu Path: uunet!mimsy!chris