henry@utzoo.uucp (Henry Spencer) (02/08/90)
In article <2093@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes: > I suspect that you have never used Multics and don't recall that UNIX >was written because there was not enough access to Multics. This is a rather drastic oversimplification. Unix was not just "Multics on a low budget", it was also "90% of the benefits at 10% of the cost". Remember that Multics and OS/360 are the two classic examples of second- system effect (overconfidence after a successful first system leads to vast complexity and a union-of-all-wishlists approach on the second). With the benefits of hindsight and a much more manageable system, Unix ended up taking a lot of ideas much farther than Multics did. >UNIX is just >beginning to implement some of the ideas which have been working in >Multics for two decades, such as mapping files to memory. Gee, how could we ever have lived without that for two decades? :-) Maybe because we don't need it and it doesn't buy us very much? Unix evolution is now largely controlled by the marketdroids, who evaluate systems by the length of the checklist of features. All sorts of silly and bizarre features are now crawling out of the woodwork and burrowing into Unix as a result. This does not necesarily mean said features are good or desirable or even useful. > The only reason Multics is not where UNIX is today is that it was >developed by one company which didn't know how to sell computers and >then rights went to another... I can think of several other reasons, actually, starting with Multics being much larger, being much fussier about memory management and such, and performing very poorly by comparison. Unix did not suddenly spring into its position of prominence when hardware reached current levels -- it steadily grew into it through ability to run well on small machines (most Unix machines were small until very recently) and ability to port to almost anything. Multics had no hope of ever copying that. -- SVR4: every feature you ever | Henry Spencer at U of Toronto Zoology wanted, and plenty you didn't.| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
davecb@yunexus.UUCP (David Collier-Brown) (02/08/90)
In article <2093@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes: | UNIX is just | beginning to implement some of the ideas which have been working in | Multics for two decades, such as mapping files to memory. henry@utzoo.uucp (Henry Spencer) writes: | Gee, how could we ever have lived without that for two decades? :-) | Maybe because we don't need it and it doesn't buy us very much? Unix | evolution is now largely controlled by the marketdroids, who evaluate | systems by the length of the checklist of features. All sorts of | silly and bizarre features are now crawling out of the woodwork and | burrowing into Unix as a result. This does not necesarily mean said | features are good or desirable or even useful. From a Multician: the scheme for mapping files into memory on Multics was very simple by comparison to some of the Unix add-ons, and well integrated into the architecture. Marketers often err in the direction of adding incompatable, ill-conceived versions of usefull features... just to say they "have" them. Very bluntly, Multics-style unification of the concept of a named file and a named memory segment is one of the things that was best left out of Unix. To put it in at this stage of the game is to turn a OS noted for its elegant file system inside-out... To make files depend on the details of (some particular) Unix memory managment is to select an inauspicious kludge as your distinguishing feature. Now if you want to rethink it from scratch, and **design** it in, thats another story. Maybe named Mach. --dave -- David Collier-Brown, | davecb@yunexus, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave Willowdale, Ontario, | Joyce C-B: CANADA. 416-223-8968 | He's so smart he's dumb.
khb@chiba.Eng.Sun.COM (Keith Bierman - SPD Advanced Languages) (02/09/90)
In article <1990Feb7.221800.804@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >UNIX is just >beginning to implement some of the ideas which have been working in >Multics for two decades, such as mapping files to memory. Gee, how could we ever have lived without that for two decades? :-) Maybe because we don't need it and it doesn't buy us very much? While we are getting away from hw.arch, this is a sensible sw.arch question. I beg to differ with you on this. mmap() is a huge win, in performance, in conceptual simplicity for the obvious uses in speeding up IO and also it allows for a very elegant way for different processes to share common memory under dynamic program control. -- Keith H. Bierman |*My thoughts are my own. !! kbierman@Eng.Sun.COM It's Not My Fault | MTS --Only my work belongs to Sun* kbierman%eng@sun.com I Voted for Bill & | Advanced Languages/Floating Point Group Opus | "When the going gets Weird .. the Weird turn PRO" "There is NO defense against the attack of the KILLER MICROS!" Eugene Brooks
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (02/09/90)
In article <1990Feb7.221800.804@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: | Gee, how could we ever have lived without that for two decades? :-) | Maybe because we don't need it and it doesn't buy us very much? There are lot of things we don't *need* which really improve life to have. Having used direct mapping of files on multics and VMS, I can say that in those cases the logic was simpler, the source smaller and more readable, the executable smaller, and the performance better. File mapping, for background, means treating a file like an array. It eliminates the explicit calls to seek and restrictions about mixing read and write without an intervening seek. It allows elements from the file to be used in expressions without lots of explicit file io, and replaces the runtime and kernel buffering scheme with the kernel page mechanism, which is often much faster. In VMS the performance gain was about 30%, and the program was smaller as well. We lived without many things, and I thought you were a defender of a lot of them, such as C standards, symbolic debuggers, etc. You're right that we can live without them, but totally wrong about "it soesn't buy us very much." Perhaps someone who has used the BSD mapping (is is mmap()?) could give us some actual timings on unix, since my experience is with other systems. Is mapping in V.4??? Examples I/O code: /* update the current record */ temp.units = 4; fseek(wkfile, (long)currec * sizeof(temp), 0); fwrite((char *)&temp, sizeof(temp), 1, wkfile); currec++; /* write moved the record pointer */ /* read the next, fseek to allow read after write */ fseek(wkfile, 0L, 1); /* NULL seek */ fread((char *)&temp, sizeof(temp), 1, wkfile); /* use the value */ m = 20 * temp.headlimit; mapped: /* something *like* this does the mapping, like open */ work = (struct demo *)mmap(filename, "r+"); /* here's the actual code */ work[currec++].units = 4; m = 20 * work[currec].headlimit; ________________________________________________________________ Okay, I typed it in, please don't tell me there are typos or I left out something, unless it is major. I just think this makes really easier code to write and maintain. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "Stupidity, like virtue, is its own reward" -me
peter@ficc.uu.net (Peter da Silva) (02/09/90)
In article <KHB.90Feb8102112@chiba.Eng.Sun.COM> khb@chiba.Eng.Sun.COM (Keith Bierman - SPD Advanced Languages) writes: > I beg to differ with you on this. mmap() is a huge win... The problem, I believe, is not that MULTICS provided mapped files. The problem is that they didn't provide any other form of file, and that mapped files in MULTICS were limited in size to a segment... though later multisegment files became available. How did MULTICS handle objects that didn't look like large arrays: terminals, tapes, and other things that fit well into the UNIX streams model? -- _--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'
barmar@think.com (Barry Margolin) (02/09/90)
O boy! In case we weren't having enough fun NeXT-bashing, now it's time to bash poor, defenseless Multics.... I've directed followups to comp.misc, because this isn't really about architecture. In article <1990Feb7.221800.804@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <2093@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes: >> The only reason Multics is not where UNIX is today is that it was >>developed by one company which didn't know how to sell computers and >>then rights went to another... >I can think of several other reasons, actually, starting with Multics >being much larger, being much fussier about memory management and >such, and performing very poorly by comparison. Unix did not suddenly >spring into its position of prominence when hardware reached current >levels -- it steadily grew into it through ability to run well on small >machines (most Unix machines were small until very recently) and ability >to port to almost anything. Multics had no hope of ever copying that. Everything you say about Multics is true. It was heavily dependent on the architecture of the Honeywell (formerly GE) mainframes. For most of its lifetime about the only other machines with the necessary features were the IBM 370 and its followons and Burroughs systems. The first microprocessor that could reasonably support a Multics-like OS was the 80386 (a friend of mine claims to have implemented a small Multics clone for the 386). But I don't think this was the reason why Multics didn't sell well. For most of the 70's, the points you make were not very important considerations in the mainframe computer marketplace. GCOS wasn't portable, and ran on almost the same processors as Multics, yet Honeywell was able to sell orders of magnitude more GCOS systems than Multics systems. I've heard of cases where a Honeywell customer wanted to buy a Multics system and the salesman tried to talk him into GCOS! Your points would explain why Multics didn't sell well into the small business market, but no one ever claimed that was Multics's target market. Multics was designed to be a computer utility, taking advantage of economies of scale (is symmetrical multiprocessing one of those things we don't really need?). Compare it to other utilities, such as phone systems: there are different considerations when designing a PBX than a central office switch. 5ESS wouldn't be expected to be portable to the hardware for an office PBX. The question isn't why PDP-11 Unix sold better than Multics, but why VM/CMS did. Regarding whether Multics's feature are "needed", over the years I've been amazed at the number of requests for facilities I've seen in the Unix newsgroups where Multics has had that feature for fifteen years. Things like prioritized printing and batch queues, better process priority control, useful library routines (e.g. for wildcard matching), decent backup facilities, interprocess communication, and user-mode device drivers. One might argue that the hardware-supported security mechanisms aren't really required, but the hardware support is precisely what is needed to protect against viruses efficiently (see comp.virus for discussions about hardware support to limit the capabilities of programs to modify other programs); the originial Multics implementation did most of it in software, and there were known security holes that were closed when hardware rings were implemented. And Multics's performance problems weren't directly related to its features. The Honeywell processors on which Multics ran lagged behind the industry in performance. This may have been partly because the additional features Multics required had to be grafted on after the processor was designed for GCOS. Around the time Multics was cancelled they finally designed a processor for GCOS on which Multics could have run directly (actually, it had a minor problem with null pointers -- it would fault upon loading (not indirecting through) them), but Multics was never ported to it. Actually, the hardest thing about porting Multics to an entirely different architecture would have been fixing all the "fixed bin (17)" and "fixed bin (35)" declarations in nearly every single PL/I source file. Demand-paged virtual memory is about all it really requires from the hardware, and no one would think of doing a serious timesharing system without this these days. The dynamic linker could be reimplemented without the special hardware support that the Honeywell processors provided. And hardware segmentation isn't really necessary; a flat address space can be treated as segmented merely by calling the high-order N address bits the segment number, and using software to manipulate all the pages of a software segment as a unit; hardware segmentation is mostly a way to implement larger address spaces with smaller MMU tables, since many of the attributes of a page are common to all the pages in a segment (such as access modes and location on disk). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) (02/09/90)
In article <1990Feb7.221800.804@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <2093@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes: >>UNIX is just >>beginning to implement some of the ideas which have been working in >>Multics for two decades, such as mapping files to memory. >Gee, how could we ever have lived without that for two decades? :-) >Maybe because we don't need it and it doesn't buy us very much? I cannot let this pass without rebuttal. I could just as well say "Tenex/TOPS-20 lived without pipes and a powerful shell for 21 years because pipes/shell weren't needed and they didn't buy very much." This is perhaps true; TOPS-20 hackers spent all their time in TECO/EMACS and DDT. The equivalent of the "quick shell script" was the "quick DDT program". I could just as well say "programmers on micros lived without anything more advanced than DOS and BASIC for years. C and Unix aren't needed and don't buy very much." 1/2 :-) File/memory mapping, or more precisely, the integration of the virtual memory system and the filesystem, is perhaps one of the most important and useful features of an operating system which has it. I am talking about full-fledged mapping, which you can have muliple read/write maps of the same file segment across multiple processes. File management on Unix is horrible. Anyone who tries to implement a database (e.g. an electronic mail system) for Unix knows how difficult it is to do something as simple as a robust and safe file lock. Let's not even mention multiple simultaneous file access and interprocess semaphores. Many of the algorithms I used in TOPS-20 software had to be replaced (not just translated from assembly to C) because they were *unimplementable* in Unix. In many cases, I had to write complex scheduling and polling algorithms to replace a simple blocking algorithm that depended upon file/memory mapping and semaphores. Now, I may accept the claim that file/memory mapping will be less useful on Unix, because it won't be standard on every Unix system (and hence you're forced to write the non-mapping code anyway). It should have gone into the first versions of BSD; it's a bit late now. That does not mean that it is something that programmers of the future should have to "live without". Even Unix will become history some day. _____ ____ ---+--- /-\ Mark Crispin Atheist & Proud _|_|_ _|_ || ___|__ / / 6158 Lariat Loop NE R90/6 pilot |_|_|_| /|\-++- |=====| / / Bainbridge Island, WA "Gaijin! Gaijin!" --|-- | |||| |_____| / \ USA 98110-2098 "Gaijin ha doko ka?" /|\ | |/\| _______ / \ +1 (206) 842-2385 "Niichan ha gaijin." / | \ | |__| / \ / \ mrc@CAC.Washington.EDU "Chigau. Gaijin ja nai. kisha no kisha ga kisha de kisha-shita Omae ha gaijin darou." sumomo mo momo, momo mo momo, momo ni mo iroiro aru "Iie, boku ha nihonjin." uraniwa ni wa niwa, niwa ni wa niwa niwatori ga iru "Souka. Yappari gaijin!"
khb@chiba.Eng.Sun.COM (Keith Bierman - SPD Advanced Languages) (02/09/90)
In article <5672@blake.acs.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
Now, I may accept the claim that file/memory mapping will be less
useful on Unix, because it won't be standard on every Unix system (and
It is part of the published feature list for V.4. So it will at least
be on all UI derived platforms, and one strongly suspects that this is
a feature that OSF will have no choice but to offer.
--
Keith H. Bierman |*My thoughts are my own. !! kbierman@Eng.Sun.COM
It's Not My Fault | MTS --Only my work belongs to Sun* kbierman%eng@sun.com
I Voted for Bill & | Advanced Languages/Floating Point Group
Opus | "When the going gets Weird .. the Weird turn PRO"
"There is NO defense against the attack of the KILLER MICROS!"
Eugene Brooksjohnl@esegue.segue.boston.ma.us (John R. Levine) (02/09/90)
In article <KHB.90Feb8175209@chiba.Eng.Sun.COM> Keith Bierman writes: >In article <5672@blake.acs.washington.edu> Mark Crispin writes: > Now, I may accept the claim that file/memory mapping will be less > useful on Unix, because it won't be standard on every Unix system (and >It is part of the published feature list for V.4. So it will at least >be on all UI derived platforms, and one strongly suspects that this is >a feature that OSF will have no choice but to offer. We put it into AIX some years ago. I'm not sure the interface is the same; in AIX it's a funny kind of shmat() but the semantics are quite obvious. It was in response to requests from data base types who found it to be useful for implementing multiple simultaneous data base users, since it gets rid of a whole layer of buffering and hence synchronization problems. AIX also lets you map a file copy-on-write and then commit the changes back atomically. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl "Now, we are all jelly doughnuts."
barmar@think.com (Barry Margolin) (02/09/90)
In article <WRM1FGGxds13@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >How did MULTICS handle objects that didn't look like large arrays: ^^^ please use the present tense. While new releases are no longer being developed, most of the Multics systems sold are still in use. >terminals, tapes, and other things that fit well into the UNIX streams >model? Multics has an I/O library, which supports device-independent access to stream and block mode sinks/sources (I don't say "devices", because the I/O library also supports stream/sequential access to virtual devices). In the "attach" call the type of device being accessed is specified as a character string, and the dynamic linker is used to convert this to a procedure pointer; this procedure then fills in a structure with procedure pointers for other operations on the device, and this collection of procedures is known as an I/O module. The actual access to particular devices is implemented by ideosyncratic system calls, but the I/O module provides a standard interface. There's even an I/O module that makes segments and multisegment files look like stream, sequential, or keyed files. There are several advantages of this mechanism over the traditional style of device access. First of all, the kernel isn't cluttered with lots of code that just converts device-specific operations into device-independent operations; the only thing that really needs to be in the kernel is the low-level device access and access control. Second, not all virtual devices need any kernel support, and they are implemented entirely in user code; why should /dev/null access require a system call? Third, since I/O modules are user mode libraries it's easy for users to implement their own virtual devices, and these were used similarly to Unix filters (I admit that I/O modules are not as easy to write as Unix filters). The Multics equivalent to the Unix termcap and curses libraries is an I/O module that implements type-independent access to video terminals; ioctls implement window operations, while stream input invokes an Emacs-style input editor. The major disadvantage is that most Multics programs are designed to access memory-mapped files rather than use the generic I/O library, so it isn't as easy to supply alternate input sources and output sinks to those programs. But most programs don't need to access arbitrary devices, so it wasn't perceived as a big problem (but this may be a case where you don't miss what you haven't had). A few years ago we added pipes to the Multics shell; the syntax permits specifying I/O modules after the equivalent of < and >, and also provides a way for input from an I/O module to be collected into a temporary file and the pathname substituted into the command line. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
throopw@sheol.UUCP (Wayne Throop) (02/11/90)
| From: davecb@yunexus.UUCP (David Collier-Brown) || henry@utzoo.uucp (Henry Spencer) || Gee, how could we ever have lived without that for two decades? :-) || Maybe because we don't need it and it doesn't buy us very much? | Very bluntly, Multics-style unification of the concept of a named file and | a named memory segment is one of the things that was best left out of Unix. I don't agree that Unix has really "lived without" that feature, or that it was totally "left out" (though certainly it *was* left out in the strong form in which it occurs in Multics). Many, many, many Unix vendors (essentially all those that provide paging instead of swapping) do the moral equivalent of mapping (portions of) executable files into (portions of) multiple process address spaces, with true faulting to the file itself. | Now if you want to rethink it from scratch, and **design** it in, thats | another story. Very true. This is a case where Unix has adopted the position it has by slow accretion and not by careful forethought (or even rethought). It is all very well to say that Unix can get 90% of the benefit for 10% of the cost by selectively implementing some but not all ways in which files can be memory mapped, but this tradeoff has clearly not been carefully thought out. I'd say that *at* *least* the ability to page or swap into a filesystem instead of a specially formatted "swap area" should have been included in that 90% gotten for 10%. Whether memory mapping of files visible to users is more arguable, but I think it certainly isn't nearly as hard to do as some implementation have made it in the past. In any event, it is I think clearly premature and too abrupt to simply dismiss file mapping to memory (with whatever semantics) as a frill not worth considering. (Henry and/or David might agree with this, but it seemed from their postings that they were too eager to dismiss consideration of file mapping, either to a never-worthwhile category or to an only-an-acedemic-issue-as-yet category.) -- Wayne Throop <backbone>!mcnc!rti!sheol!throopw or sheol!throopw@rti.rti.org
pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) (02/12/90)
In article <1990Feb7.221800.804@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: This is a rather drastic oversimplification. Unix was not just "Multics on a low budget", it was also "90% of the benefits at 10% of the cost". Or rather 10% of the benefits for 10% of the cost. I am hard pressed to think that the cost/benefit ratio of Multics was lower than that of V7 Unix; there are lots of things that are impossible to do efficiently under V7 Unix, and trivially easy under Multics (use Multics RDMS, and then read what Stonebraker has to say about how suitable is Unix for Ingres). With Unix you get the 10% of the benefits that are ideal for sw development (editing, compiling), and at 10% of the cost every little CS Dept. in the country could buy a PDP-11. Remember that Multics and OS/360 are the two classic examples of second- system effect (overconfidence after a successful first system leads to vast complexity and a union-of-all-wishlists approach on the second). To put Multics and OS/360 in the same phrase is offensive. Multics was very clearly designed to be as orthogonal and lean as possible, and it largely succeeded. The overconfidence was in breaking a lot of new ground, not in the inexistent morass of features. It was a research project after all. With the benefits of hindsight and a much more manageable system, Unix ended up taking a lot of ideas much farther than Multics did. Like that interesting but misconceived hack, pipes? As to anything else, I cannot really imagine any Unix idea that is not a crippling of a Multics idea (e.g. the setuid bit). The quality of Unix stems from the extremely intelligent selection of the 10% of the Multics functionality that could be implemented or ported on a PDP-11. It takes real greatness to get it right, and to provide such usefulness with so little. The history of Unix after V7 (and before it), within and without AT&T, is really a series of grotty attempts, culminated in SVR4, to put in back the missing 90%, as HW architectures become less constraining than a PDP's. >UNIX is just >beginning to implement some of the ideas which have been working in >Multics for two decades, such as mapping files to memory. Gee, how could we ever have lived without that for two decades? :-) Painfully. And only because much of the "progress" of CS in this twenty years has been expansion, not advancement. The success of Unix vs. Multics (even if this competition never quite existed) can be seen as a colossal catastrophe, if one looks at the slowing down in operating system evolution it has caused, much like OS/360, or as a great success, because it has lead to an expansion of the field. It has elevated the median, but not the average. Maybe because we don't need it and it doesn't buy us very much? Again, compare RDMS with Ingres; or confer with News. > The only reason Multics is not where UNIX is today is that it was >developed by one company which didn't know how to sell computers and >then rights went to another... I can think of several other reasons, actually, starting with Multics being much larger, being much fussier about memory management and such, and performing very poorly by comparison. This is entirely ridiculous. Multics performance, except on the very early machines without hardware assist for rings, has always been *excellent*. I have seen relatively underpowered systems (a 6000 could do 1 MIPS with 1 MW, and could still run quite a few users) sustain dozens of users with grace. I am quite sure, but cannot quote numbers to say this, that with Multics and SUN machines of equivalent power, Multics will give better response times. Mach, which is a kind of latter day, higher overhead, Multics like Unix, is reported outperforming VM Unix. As to Multics being much larger, let's compare the line counts listed in the MIT TR on the kernelization of its nucleus, with the line counts of 4.3BSD. As to fussiness about memory management, it only really requires virtual memory with restartable/continuable faults. Note: what I said about Multics applies in slightly reduced form to TENEX, and in a more emphatic form (modulo some oddity) to MUSS, and with some proviso to Accent/Mach. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
jkrueger@dgis.dtic.dla.mil (Jon) (02/12/90)
pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) writes: >(use Multics RDMS, and then read what Stonebraker >has to say about how suitable is Unix for Ingres). A reading from the book of Stonebraker, The INGRES Papers: Anatomy of a Relational Database System, Chapter 8, Operating System Support for Database Management, (originally CACM 24:7, July 1981): "A DBMS would prefer a small efficient operating system with only desired services provided ... most general purpose operating systems provide all things to all people at much higher overhead. Hopefully, future operating systems will be able to provide both sets of services in one environment." The paper is a nice overview of alternatives which lead to this conclusion. One section deals with how DBMS might use mapping files into address spaces. One tradeoff examined is the overhead of page tables, the time cost of faulting the tables or the space cost of keeping them resident. The alternate of mapping "chunks" of the file into the space (as discussed here) has its own tradeoff: increased complexity and the overhead of each mapping operation. Mapping each chunk into a separate space isn't mentioned, or using sparse spaces. -- Jon -- Jonathan Krueger jkrueger@dtic.dla.mil uunet!dgis!jkrueger The Philip Morris Companies, Inc: without question the strongest and best argument for an anti-flag-waving amendment.
dworkin@salgado.Solbourne.COM (Dieter Muller) (02/12/90)
In article <2106@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes: > > In VMS the performance gain [from the mmap()-equivalent] was about >30%, and the program was smaller as well. [...] > > Perhaps someone who has used the BSD mapping (is is mmap()?) could >give us some actual timings on unix, since my experience is with other >systems. Is mapping in V.4??? I've had to do a lot of file checksumming in the last few months. Since this takes approximately forever on a 30+ MB file, I finally sat down and merged the mmap() code out of cp(1) and the checksumming code out of sum(1). On a single-CPU Series4 Solbourne system: salgado {44} time fastsum /image/os/4.0C/upgrade/USR.tar > /dev/null 37.3u 11.4s 0:55 87% 0+648k 4+0io 3612pf+0w salgado {45} time sum /image/os/4.0C/upgrade/USR.tar > /dev/null 65.4u 17.0s 1:28 92% 0+184k 3533+0io 3554pf+0w salgado {46} ls -l /image/os/4.0C/upgrade/USR.tar -rw-rw-r-- 1 root 29458432 Jan 12 16:15 /image/os/4.0C/upgrade/USR.tar I did fastsum first, so there wouldn't be any buffered blocks left over from the `real' sum run (physical memory on this system is 32 MB, so it is possible, though unlikely, with an Emacs running...). The chunk size (amount mapped at a time) is 1 MB. This is the same chunk size used by cp(). Since I seem to be CPU-bound at this point, there's no advantage to making it larger. Also, the system load average was baselined at 0.45, during fastsum it peaked at 0.88, and during sum, it peaked at 1.2. The significance? You tell me. Dworkin -- Martha, the platypus is into the rutabagas again! boulder!stan!dworkin dworkin%stan@boulder.colorado.edu dworkin@solbourne.com Flamer's Hotline: (303) 678-4624 (1000 - 1800 Mountain Time)
dmr@alice.UUCP (02/12/90)
These Multics interchanges are enchanting; such a delightful combination of thinly-veiled envy, nostalgia, and the occasional gloriously stupid claim. About three years ago there was another such discussion, and I wrote a short essay on what people were saying then. I can't remember if I ever posted it; probably not, since it sort of trails off without ending in much of a conclusion. Perhaps it's time to trot it out now and get some (more?) use out of it. Dennis Ritchie dmr@research.att.com att!research!dmr Subject: who needs Multics? [written early 1987] I've been following the Multics discussions with considerable interest. I was involved in Multics at an early stage and retain strong, though by now sightly fuzzy impressions of it. Obviously, they have been influenced by subsequent heavy involvement in Unix. One might characterize Multics as a system that tried to do everything, that had a grand conception of a new order for the world, and then had to contract considerably as various realities intruded. Ultimately, it seems, it has had to contract into nothing, although during its lifetime, it did achieve a great many of its design goals. And it has been quite influential. Unix, by contrast, started with a modest but exceedingly well-conceived design that has, so far at least, been able to accommodate enormous expansion in various directions, only some of which aim towards the most characteristic features of Multics. We have always been assiduous in acknowledging a strong debt to Multics and its immediate predecessor (CTSS); still, many components of this connection are by now so thoroughly assimilated into the culture that it is hard even to see them. Hugh LaMaster mentions TSS, IBM's answer to Multics. TSS did emulate some aspects of Multics; in particular it approximated the single-level store discussed below, but in other, crucial aspects it utterly missed the point. For example, TSS poisoned the user (and program) interface with JCLish, IBMish DD cards describing all sorts of wretched, irrelevant facts about files, instead of doing the job properly. The most characteristic feature of Multics, the design aspect that strikes one most strongly, is indeed the single-level store: the notion that files (in a directory hierarchy) are identified with segments (parts of the address space). Other systems have done this since and perhaps even before, but Multics is the system that tried most publicly and boldly. I think the effort was admirable, was worth trying, and may still hold life, but seems now to be flawed. Even though the underlying mechanisms were unified, there are really two separate aspects to the single-level store: program and data. The program aspect is the dynamic linking facilities that have been discussed (and envied) in this forum. Briefly, it means that use of a name in call-position `func()' causes the system to search, at runtime, in specifiable places, for a file containing the appropriate entry point, to attach the file to the address space, and to complete the linkage to the function. This is slow the first time, rapid thereafter. All in all, this was made to work well, and the effect is more elegant, transparent, and general than the `shared libraries' that one finds in many systems. It was however never fast enough in practice to be the universal mechanism for linking; very early in the game, the `binder' had to be introduced that bundled together libraries and commands in advance, to avoid the overhead of doing it every time the command was executed. At least in the early days, another, and important, Multics compromise had especially evil consequences. The original design called for each command to be executed in a new process, as is done in Unix. This was much too slow, largely owing to dynamic linking. (I remember the time to start a new process going from perhaps 20 CPU minutes, to a few seconds at the time we left the project.) Therefore, in Multics all one's commands execute in the same process, and use the same address space. This was fine so long as you were not changing any of the programs you were running. Say you recompiled the sine routine and ran your test program again. At best, the program would continue to use the old sine because that version was already linked into your address space (this was merely confusing); at worst, the test program would jump into the wrong place in the new sine routine (the segment contents were replaced but the old offset remained in the linkage table). This effect was known as "the KST problem" (KST= Known Segment Table) and the result was called "being KSTed." I am certain that it was papered over in later versions of the system, and modern Multics users may not even be aware of the problem, but it was a real pain for us. (Our general fix was to type hcs_$newproc and go get a cup of coffee.) In spite of the problems (they were eventually alleviated) the dynamic linking of programs probably can be counted a success. I don't thing the same is true of data. It is generally a pleasant, and almost universally applicable abstraction to imagine other programs appearing, and thereafter statically living in your own program's address space. The same abstraction simply fails in the case of data. Other people have pointed out the problems already; I'll reiterate: 1) Much data comes from devices that cannot convincingly be mapped (terminals, tapes, raw disks, pipes) 2) In the state of technology, even plain files cannot be mapped properly, because they are too big (I might need some correction on the second point, but I don't see how the Multics machine could deal transparently with segments larger than 256KW.) What actually happened was that, for the most part, people avoided the "single-level store" for data and used sequential IO via read and write calls. The Multics IO system was quite snazzy, and one of the first things we did with it was to write the "fsim"-- the file system interface module, that initiated your segment and put/got bytes in it, and did all the grotty but necessary things like set_bit_count. In other words, as a "feature," occasional use of data file mapping was convenient, but as an organizing principle, as a way of life, it was a bust; it was something that had to be programmed around.
davecb@yunexus.UUCP (David Collier-Brown) (02/12/90)
In article <1990Feb7.221800.804@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: | Remember that Multics and OS/360 are the two classic examples of second- | system effect (overconfidence after a successful first system leads to | vast complexity and a union-of-all-wishlists approach on the second). pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) writes: | To put Multics and OS/360 in the same phrase is offensive. | Multics was very clearly designed to be as orthogonal and lean as | possible, and it largely succeeded. The overconfidence was in | breaking a lot of new ground, not in the inexistent morass of | features. It was a research project after all. I have to disgree with both of you here! Multics really was "designed", (as opposed to OS/360, which was accreted), and it was an unusual act at the time to set out the goals and algorithms that were to be used to achieve them in formal research papers beforehand. [ref: (a) the MIT Multics papers, various ACM articles (b) personal communication, one of the designers of CICS) Multics was supposed to be a production-quality computing service, thus the name "MULTiplexed Computing Service". It was by no means a research project. That it was not a research project annoyed Honeywell (who loved GCOS) no end, leading to the strange algorithm: if year % 2 then announce cancellation of Multics else announce next release of Multics --dave -- David Collier-Brown, | davecb@yunexus, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave Willowdale, Ontario, | Joyce C-B: CANADA. 416-223-8968 | He's so smart he's dumb.
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (02/12/90)
In article <1990Feb12.053616.11455@Solbourne.COM> dworkin@salgado.UUCP (Dieter Muller) writes: | On a single-CPU Series4 Solbourne system: | | salgado {44} time fastsum /image/os/4.0C/upgrade/USR.tar > /dev/null | 37.3u 11.4s 0:55 87% 0+648k 4+0io 3612pf+0w | | salgado {45} time sum /image/os/4.0C/upgrade/USR.tar > /dev/null | 65.4u 17.0s 1:28 92% 0+184k 3533+0io 3554pf+0w | | salgado {46} ls -l /image/os/4.0C/upgrade/USR.tar | -rw-rw-r-- 1 root 29458432 Jan 12 16:15 /image/os/4.0C/upgrade/USR.tar This matches very well for the 30-40% I saw on VMS. Considering another entire type of CPU, o/s, and vendor, I would say it's closer than I expected. I feel better now saying that there is a gain, and that it is not 2:1 in most cases. | Also, the system load average was baselined at 0.45, during fastsum it | peaked at 0.88, and during sum, it peaked at 1.2. The significance? | You tell me. I guess I would conclude that it was worth doing in some applications, and not try to quantify too much. If you do this often I'm sure you think the effort was well worth it. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "Stupidity, like virtue, is its own reward" -me
trt@rti.UUCP (Thomas Truscott) (02/13/90)
[someone wrote a replacement for "sum", called "fastsum" that uses mmap().]
You are comparing your efficient "fastsum" that happens to use mmap()
against a sluggardly "sum" that happens to use read().
(Actually it uses getchar(), which calls _filbuf(),
maybe _filbuf() uses mmap()?!)
The following would be a more appropriate test:
Change your fastsum routine so that instead of mmap()ing
a megabyte at a time, it does a read() of a megabyte at a time.
Compare the mmap() and read() versions of this program.
I suspect you will find they take about the same amount of time.
On a Sparcstation 1, try timing "cp" vs. the following program:
main()
{
char bfr[8192];
register int n;
while ((n = read(0, bfr, sizeof(bfr))) > 0)
write(1, bfr, n);
}
I did "/bin/time cp /vmunix /tmp/x"
and "/bin/time a.out < /vmunix /tmp/x" several times.
The results were essentially identical.
(I did not experiment with buffer sizes, I suspect 16k would be faster.)
There is no inherent reason that read() should be slower
than mmap() for sequential I/O, since read() is doing precisely
what is wanted. Indeed read() should be faster since
it is conceptually simpler.
Note that read() can be implemented with memory mapping, in some cases:
it could map the address of "bfr" to a copy-on-modify kernel page.
That would eliminate user <==> kernel data copying.
I can imagine an improved read/write and stdio resulting
from this sort of thing. But somehow I think mmap() is getting
the intellectual juice these days.
As others have pointed out, read() and write() are generally useful
on streams, and mmap() is not.
(The SunOS "cp" command falls back to read/write if mmap() fails.
But since read/write is as fast as mmap(),
why bother with mmap() in the first place?!)
So what is mmap() good for? Plenty.
But it is NOT a replacement for read/write.
Tom Truscottdavidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (02/13/90)
In article <10468@alice.UUCP> dmr@alice.UUCP writes: | 2) In the state of technology, even plain files cannot be mapped | properly, because they are too big | (I might need some correction on the second point, but I don't | see how the Multics machine could deal transparently with | segments larger than 256KW.) Sure. I could quibble about the size, obviously 1MB is too small, but there will always be a need for a file larger than the address space. You get some real problems seeking into a file which is larger than you integer size, too, whether you use the value as a subscript or offset. You obviously need a data type which can hold the largest filesize and do arithmetic with it if you want it to be convenient. Anyone who has used really large files on typical UNIX knows the problems. | What actually happened was that, for the most part, people | avoided the "single-level store" for data and used sequential | IO via read and write calls. I suspect that this was due to the limitations of the implementation to a large extent. If the mapping had been smooth and seamless it might well have been more used. | In other words, | as a "feature," occasional use of data file mapping was convenient, | but as an organizing principle, as a way of life, it was a bust; | it was something that had to be programmed around. I think that follows. You hit the limits all the time, therefore you did it another way. I haven't had access to Multics on a regular basis for about 15 years. If anyone cares to run a file access test of i/o vs mapped methods, such as another poster did for BSD, it might be interesting. Someone might state the current filesize limit for mapping, too. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "Stupidity, like virtue, is its own reward" -me
aglew@oberon.csg.uiuc.edu (Andy Glew) (02/13/90)
>>UNIX is just >>beginning to implement some of the ideas which have been working in >>Multics for two decades, such as mapping files to memory. > >Gee, how could we ever have lived without that for two decades? :-) >Maybe because we don't need it and it doesn't buy us very much? I'm glad to see that I'm not the only one thinking this way. Memory mapped files are great if you access files like memory - if you seek around in them randomly, etc. But memory mapped files can positivel *hurt* if you do sequential scans, and your OS doesn't provide an expected access type hint to prevent the scan from emptying the existing page store. Plus, files are *large*. There are people telling me that we won't need more than 32 bits of memory address, and I already have more than that in data. (True, this is just saying let's not put a broken limit on file sizes just because we already have one on memory) On the other hand... the XMF (Xylophone Memory System) reported by HP in SOSP 89 does some interesting tricks. The main one being that software computation of the file logic disk block to physical disk block to buffer cache address computation is short-circuited by using the virtual address translation mechanisms. -- Andy Glew, aglew@uiuc.edu
henry@utzoo.uucp (Henry Spencer) (02/13/90)
In article <2106@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes: > File mapping... replaces >the runtime and kernel buffering scheme with the kernel page mechanism, >which is often much faster. > In VMS the performance gain was about 30%... I'm afraid my reaction to this is "what would the performance gain have been if the same effort had been put into speeding up normal I/O"? Modulo one or two requirements like alignment, if there is *any* real performance difference with only one process involved, it means you are comparing apples to oranges -- either the kernel I/O code has not been optimized to exploit the MMU, or you are comparing an I/O version which works (say) 512 bytes at a time to a mapped version that grabs the whole file at once. When only one process is involved, read() and write() do everything that mmap() does, and there is no reason why they should be any slower. I agree that the situation is a bit messier when multiple processes are involved... but interprocess communication is a different issue and a much messier one anyway. -- SVR4: every feature you ever | Henry Spencer at U of Toronto Zoology wanted, and plenty you didn't.| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
davecb@yunexus.UUCP (David Collier-Brown) (02/13/90)
dmr@alice.UUCP writes: | What actually happened was that, for the most part, people | avoided the "single-level store" for data and used sequential | IO via read and write calls. The Multics IO system was quite | snazzy, and one of the first things we did with it was to write | the "fsim"-- the file system interface module, that initiated your | segment and put/got bytes in it, and did all the | grotty but necessary things like set_bit_count. In other words, | as a "feature," occasional use of data file mapping was convenient, | but as an organizing principle, as a way of life, it was a bust; | it was something that had to be programmed around. I got caught on this one too: it was a serious pain to simulate a stream of characters with an array. The two are different **in nature**, and the result is repeated brain-faults by programmers (:-)). I claim the unification of the file/segment namespace was a good idea, but the unification of the "access methods" was ill-advised. To be specific: I once wrote a program that did random i/o. Its Multics variant started out using the simulation of "file" behavior of fsim (ioa_, methinks, in the version I used). At some point, I discovered the underpinnings of the module was a memory mapping, something I had no experience with nor intuitive understanding of. Surprise! This low-level construct was exactly what I didn't need: it added complexity, it had to be programmed around, it wasn't easy to understand. Not having seen Unix at the time, I didn't think of the elegant "seek", I instead thought of arrays and "record[126,5]". Bleaaaaaaa. I'll claim that one can usefully build several complete, self-consistent views of a memory-mapped file, at least one based on streams (sequences) of data, another on lines/records/structures of data, another on monotonically increasing bifurcated but synchronized streams of data (keyboard i/o) and so forth, about which an applications programmer can reason and even intuit. What I won't claim is that a "memory array of file-contents" is the kind of view I'd use in an application. Its a primitive. Its even a "good" primitive, in that one can use it to build lots of other, usefull things. But anybody who uses primitives to do substantial work **is** a primitive.(:-)). --dave -- David Collier-Brown, | davecb@yunexus, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave Willowdale, Ontario, | Joyce C-B: CANADA. 416-223-8968 | He's so smart he's dumb.
pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) (02/13/90)
In article <756@dgis.dtic.dla.mil> jkrueger@dgis.dtic.dla.mil (Jon) writes: pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) writes: >(use Multics RDMS, and then read what Stonebraker >has to say about how suitable is Unix for Ingres). A reading from the book of Stonebraker, The INGRES Papers: Anatomy of a Relational Database System, Chapter 8, Operating System Support for Database Management, (originally CACM 24:7, July 1981): I was actually thinking of the retrospection paper (very good reading! very amusing, and candid, and full of humour, and really useful). The OS support paper you cite looks, in my opinion, a bit skewed by the mention of Pr1mos, which is after all a Multics inspired system. Stonebraker constantly gripes against the lack of locking, the lack of suitable IPC instead of pipes, the buffered nature of file system IO, the inability to guarantee writes, the coarse protection system (and the limited address space of the PDP-11, a problem later obviated by the VAX), the lack of shared memory, of shared libraries, etc... The Ingres people spent an appalling amount of effort fighting the limitations of the os, and building grotty work arounds, instead of concentrating fully on their job. The RDMS people didn't have such problems. Ingres and RDMS are both successes, but RDMS is obviously far smoother. So, you ask, why did they use Unix at all, and on a PDP-11 as to that? Herein lies the answer to our discussion: Unix was free, the PDP-11 inexpensive, and the time of grad students essentially free as well. By contrast Multics would cost a lot, run on very expensive hardware, and require expensive system programmers. In other words, a computing center thing. Unix was written by people that wanted their own little inexpensive thing, and did not like using the computer center, and this was like the Ingres project, and the people they wanted their database work for. Beyond all the discussion of technical issues, they built a system that was fit economically and politically very well (except for one major detail) the same environment as most CS departments and VARs targeting small businesses, and rode on the wave of the (super)(mini/micro)computer boom, the single largest development in the computer business, that has made the fortunes of DEC, Apple, SUN, COMPAQ, IBM ESD, SCO, at one time or another. "A DBMS would prefer a small efficient operating system with only desired services provided ... most general purpose operating systems provide all things to all people at much higher overhead. Hopefully, future operating systems will be able to provide both sets of services in one environment." I think that Multics fits the bill here. It has a very small set of primitive concepts, and very few low level services. It builds on those an all-singing all-dancing set of higher level ones, but you can cut through all those. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
lm@snafu.Sun.COM (Larry McVoy) (02/14/90)
In article <1990Feb12.204658.18336@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <2106@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes: >> File mapping... replaces >>the runtime and kernel buffering scheme with the kernel page mechanism, >>which is often much faster. >> In VMS the performance gain was about 30%... > >I'm afraid my reaction to this is "what would the performance gain have >been if the same effort had been put into speeding up normal I/O"? >Modulo one or two requirements like alignment, if there is *any* real >performance difference with only one process involved, it means you >are comparing apples to oranges -- either the kernel I/O code has not >been optimized to exploit the MMU, or you are comparing an I/O version >which works (say) 512 bytes at a time to a mapped version that grabs >the whole file at once. When only one process is involved, read() and >write() do everything that mmap() does, and there is no reason why they >should be any slower. Let's see, read: get the block from disk copy it out to the user buffer return mmap: get the block from disk map it into the user's address space return It seems to me that there is in extra copy in there. In kernels that I've profiled, this copy shows up very high on the list (in the top 2 or 3). >SVR4: every feature you ever | Henry Spencer at U of Toronto Zoology >wanted, and plenty you didn't.| uunet!attcan!utzoo!henry henry@zoo.toronto.edu --- What I say is my opinion. I am not paid to speak for Sun, I'm paid to hack. Besides, I frequently read news when I'm drjhgunghc, err, um, drunk. Larry McVoy, Sun Microsystems (415) 336-7627 ...!sun!lm or lm@sun.com
jonah@db.toronto.edu (Jeffrey Lee) (02/14/90)
lm@snafu.Sun.COM (Larry McVoy) writes: >read: > get the block from disk > copy it out to the user buffer > return >mmap: > get the block from disk > map it into the user's address space > return >It seems to me that there is in extra copy in there. In kernels that I've >profiled, this copy shows up very high on the list (in the top 2 or 3). What about: read: if (pagealigned(buffer) and multipage(buffer)) { read the blocks from disk into the user's buffer } else { get the blocks from disk copy it into the user's buffer } The test should be *very* cheap in comparison to the rest of what is being done and will avoid the copying. It also means *less* changes to existing user code -- just enough to make sure that read buffers are page aligned. Simply changing stdio and recompiling libc and applications should speed up a large fraction of code *without* having to rewire it use a *different* access policy (mmap) or to special case stream vs file i/o. The changes to the system are (a) localized, and (b) affect large numbers of applications. Jeff Lee -- jonah@cs.toronto.edu
aglew@oberon.csg.uiuc.edu (Andy Glew) (02/14/90)
>read: > get the block from disk > copy it out to the user buffer > return > >mmap: > get the block from disk > map it into the user's address space > return > >It seems to me that there is in extra copy in there. In kernels that I've >profiled, this copy shows up very high on the list (in the top 2 or 3). How about: read: get the block from disk if the user buffer is page aligned map it into the user address space else copy it return or even, if you are expecting the data not to be reused, and your I/O system can do copies to arbitrary locations read: lock the pages containing the user buffer down tell the I/O controller to write directly into the user memory. -- Andy Glew, aglew@uiuc.edu
gd@geovision.uucp (Gord Deinstadt) (02/21/90)
In article <1635@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >As you see the argument is not simple. My own hunch is that mmap is >definitely superior for things that require an arraysh view of the world, as >it encourages taking notice of important things like the existence of pages, >the problems with locality, etc... It is by no means the only view of the >world, though. Terminals, tapes, etc.. you cannot mmap() (even if Mach tries ^^^^^^^^^ >hard with "memory objects", fake memory segments). You have to live >with multiple paradigms or adopt the LCD of them. But a screen *is* an arrayish device (even if your hardware connects to it with a bit hose instead of a bitmap). You wouldn't know it from programming languages though, other than spreadsheets and 4GLs. A keyboard maps more sensibly into a streamish paradigm. Until you throw in cursor keys or a mouse and allow the user to navigate freely... (In another posting you referred to a block-oriented terminal as a "card- like" device. I realize it wasn't your choice of terms in the first place, but don't you think a terminal with a form on it is more like a piece of paper than a card? A paper tape is 0-dimensional because you just get to read/punch the current character; a card is 1-dimensional and a form is 2-dimensional.) On the subject of mmap() vs read(), I think there is a deeper issue. If support for arraylike file access is included _in the language_, 1. you don't need VM hardware, 2. if you have it you can use it transparently, and 3. the compiler is free to do whatever magic it wants, knowing what you are up to. So in this case I think we could actually learn from (shudder) PDP-11 FORTRAN by including in C support for virtual arrays and for pointers into virtual arrays. -- Gord Deinstadt gdeinstadt@geovision.UUCP
pcg@aber-cs.UUCP (Piercarlo Grandi) (02/22/90)
In article <766@dgis.dtic.dla.mil> jkrueger@dgis.dtic.dla.mil (Jon) writes: pcg@aber-cs.UUCP (Piercarlo Grandi) writes: >fundamental aspect of programming . . . >the difference between encoded (paper tape) and structural >(card deck) representations of data. In encoded representations the >relationships among parts of composite data are encoded within the data, in >structural representations they are part of the data structure; in one case >you scan the data, in the other you navigate it. Consider a naming model, in which such distinctions are less than fundamental, are in fact are irrelevant. But these are based essentially on identifying entities by content, which is way above the OS architectural level we were discussing. For a specific example, consider the relational model. Well, the relational model is structural to the nth power (even if based on content location). It is the ultimate in 'card deck' style programming. The fact that relationships among tables are implicit in their contents (thos within a table of course use contiguity) simply means that they are even more out of vand than >UNIX tends to make life difficult for people doing >these things (major example being INGRES). As a user and programmer of INGRES, I find the facts otherwise. As the creator of INGRES, so does Stonebraker. Stonebraker wails for pages and pages in his "retrospection" paper and also in the "os support" one about (against) having to use pipes, not having shared memory, and not having reliable locking. The problem with Unix and the architectures it was designed for is that the kernel is an "io multiplexor", but short of major surgery (adding new modules, either properly or as a pseudo device driver) cannot provide the *foundation* (hey! I am a minimalist -- I don't want kernels to provide *services*) for such technology. Or perhaps you had in mind an operating system that has made INGRES easier to develop, use, or adapt? Would you name it? Well, my favourite example is RDMS (something quite comparable to Ingres) under Multics. The authors did not have to fight tooth and nail against the limitations of Unix for the PDP-11. Unix V7 was a *very* well designed compromise, but very much constrained by the target hardware. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
vitale@hpcupt1.HP.COM (Phil Vitale) (02/23/90)
> Re: Is mapping files into memory a big win? > Here's a cult-favorite paper that addresses this question, > "Hints for Computer System Designers", by Butler Lampson > I can't remember the source ... IEEE Software, (January 1984), pp. 11-28 Phil Vitale vitale%hpda@hplabs.hp.com