buck@siswat.UUCP (A. Lester Buck) (01/09/89)
In article <12872@steinmetz.ge.com>, davidsen@steinmetz.ge.com (William E. Davidsen Jr) writes: > I talked to four system managers who handle both > VMS and UNIX VAXen, and even those who really dislike UNIX as an > interface agree that UNIX will run 20-30% more users on a VAX, at least > when doing typical things like edit, compile, read mail, light > computation, etc. > [ ... ] > The reason is that VMS has a lot of overhead in starting a process, > and a lot in file i/o, due to the many types of file. You have some > features added in VMS (which may or may not be needed), but you pay for > them. > > I will agree with you that it is possible to write an o/s for any > given computer which will maximize performance, but it is not a given > that performance is the goal of a proprietary o/s. In fact, given the > low overhead of process startup and file i/o in UNIX, there is usually a > limited place for improvement there. Using the fast file system (BSD and > V.4) the overhead of directory access in UNIX is low. > [ ... ] > The assumption that proprietary=faster is not universally true, > although I agree that for any machine there is room to custom tailor the > software to the hardware. I was reading an article about VMS in the November 1988 issue of the tabloid "Computer Technology Review." Titled "VAX managers cautioned on accepting VMS V.5" by Clay Prestia, it mainly advises waiting for the bugs to settle out for several months. But at the end it makes an astounding statement about VMS performance over time (quoted without permission): "As time passes, [bugs will be fixed]. The performance loss probable with V.5 is a problem that one can't currently expect to see resolved as time passes. With the advent of V.5, the cumulative loss of productive capacity of VMS since V.3 now totals over 30% for many workloads. CPU hardware may be getting cheaper measured on a per cycle basis, but the software induced productivity losses negate much of this savings. Digital could restore much of the performance loss by supplying more than one variant of VMS. As Digital supplies many disparate configurations of the VAX hardware platform, it ought to supply variants of the operating system software optimized to each of the different environments. Just as Digital has been successful at making all VAX hardware configurations look the same to the user and applications, so could it succeed in doing the same with VMS variants." Contrast this with the article "The Evolution of UNIX System Performance" by J. Feder in the Unix volume of the AT&T Bell Laboratories Technical Journal, October 1984. The author presents data showing improvements of approximately 30% in various operating system performance measures in the time span from 1979 to 1983, on several different architectures (PDP-11/70, Vax-11/780 & /750, and 3B20S). Ok, so why does Unix get better with age, across architectures, while VMS gets worse with age, on a single architecture? Maybe OS's have a youth, middle age, and decline. In their youth, an OS cleans up and tunes its fundamentals to improve its performance. Then a middle age spread starts in, with no more performance gains, and maybe some loss because of creaping featurism. Finally, the load of backward compatibility and support for new features that don't mesh well with the original design lead to complete ossification and decline. Was the 1984 Unix article a measure of the youthful Unix? Is VMS creaking at the joints and well into its decline? What do the above comments about tuning for VMS workload mean, and does this have any relevance to Unix? How much have recent releases of Unix been at the expense of performance? Will System VR4, with everything AND the kitchen sink, have built in performance losses of a significant size? -- A. Lester Buck ...!uhnix1!moray!siswat!buck
rang@cpsin3.cps.msu.edu (Anton Rang) (01/09/89)
In article <370@siswat.UUCP>, buck@siswat.UUCP (A. Lester Buck) writes: >In article <12872@steinmetz.ge.com>, davidsen@steinmetz.ge.com (William E. Davidsen Jr) writes: >> I talked to four system managers who handle both >> VMS and UNIX VAXen, and even those who really dislike UNIX as an >> interface agree that UNIX will run 20-30% more users on a VAX, at least >> when doing typical things like edit, compile, read mail, light >> computation, etc. >> [ ... ] >> The reason is that VMS has a lot of overhead in starting a process, >> and a lot in file i/o, due to the many types of file. You have some >> features added in VMS (which may or may not be needed), but you pay for >> them. There is a lot of process creation overhead in VMS. On the other hand, you don't need to create a process every time you do anything (as UNIX does). In fact, most "basic" users (edit/compile/link) will log in and use only their one process (or maybe two, if they have a background editing process). The file I/O overhead is significantly more than UNIX's if you're working with only sequential files--in particular, sequential text files. Against this, balance the capabilities of indexed files. If you have an application working with large indexed files, VMS gives you much more flexibility than UNIX (which hasn't even GOT indexed files, and won't let you control disk allocation if you want to make them up yourself). >I was reading an article about VMS in the November 1988 >issue of the tabloid "Computer Technology Review." >Titled "VAX managers cautioned on accepting VMS V.5" by >Clay Prestia, [ ... ] at the end it >makes an astounding statement about VMS performance over >time (quoted without permission): > "As time passes, [bugs will be fixed]. The performance > loss probable with V.5 is a problem that one can't > currently expect to see resolved as time passes. With > the advent of V.5, the cumulative loss of productive > capacity of VMS since V.3 now totals over 30% for many > workloads. When I first saw this article, I thought "Are they serious?". After talking with a number of VMS managers, on systems ranging from 11/780s to 8000-series machines, I decided "No". I couldn't figure out what he was talking about. The one thing that seems to slow VMS V5 over VMS V4 are some changes in the paging algorithm--if you have a slow disk, the extra paging under V5 is a problem. > Digital could restore much of the performance loss by > supplying more than one variant of VMS. As Digital > supplies many disparate configurations of the VAX hardware > platform, it ought to supply variants of the operating > system software optimized to each of the different > environments. [ ... ] It's called SYSGEN. Admittedly, the documentation on it isn't as good as it should be, but you can tune your system to fit your environment VERY, VERY well using it. (When one school I was at went from untuned VMS 4.5 ==> tuned VMS 4.5, our "performance" [rather subjectively] went up nearly 100%.) You can control paging behavior (working set sizes etc.), scheduling (quantum times etc.), file I/O (cache sizes etc.), and basically anything else you'd want to do. Proper tuning really, really helps. > [ stuff about UNIX getting faster deleted ] >Ok, so why does Unix get better with age, across architectures, >while VMS gets worse with age, on a single architecture? (1) I don't believe "VMS gets worse with age" yet. (2) UNIX started out as a very, very ugly bunch of code--lots of "hacks". As parts of it are replaced (i.e. the Fast File System), it's bound to get faster--what existed before was truly awful. Also, the kernel code is being modified to make better use of the hardware over time. >Was the 1984 Unix article a measure of the youthful Unix? >Is VMS creaking at the joints and well into its decline? No. (But then again I'm biased--I use both VMS and Unix, and really hate Unix; compared to it, anything's an improvement. Well, maybe not MS-DOS.) >What do the above comments about tuning for VMS workload >mean, and does this have any relevance to Unix? See above about SYSGEN. In Unix, you don't tune--you just assume stuff will work. One other thing to remember...the environments are really targeted for different people. Unix is just not great for large business databases, for instance--maybe a few variants have support for high-efficiency databases, but that's definitely few. It doesn't even have BATCH jobs! (Let alone indexed files, ACLs [though they're in a few newer versions], and identifiers.) My opinions only, of course. Anton +---------------------------+------------------------+----------------------+ | Anton Rang (grad student) | "VMS Forever!" | "Do worry...be SAD!" | | Michigan State University | rang@cpswh.cps.msu.edu | | +---------------------------+------------------------+----------------------+
debra@alice.UUCP (Paul De Bra) (01/10/89)
In article <370@siswat.UUCP> buck@siswat.UUCP (A. Lester Buck) writes: > [long story reduced to key question: ] > >Ok, so why does Unix get better with age, across architectures, >while VMS gets worse with age, on a single architecture? > The story for VMS is that it initially ran on Vaxen (780 mostly) with little memory, and all updates/upgrades of VMS have been focusing on optimization for speed versus memory. Added features slow things down as always, but adding memory to the system and optimizing programs for speed compensates. VMS supposedly still runs reasonably fast compared to several versions ago, if you compare a machine with say 20 megabytes to an old version of VMS on the same machine with only 4 megabytes of memory. The same more or less applies to Unix as well. There have been speed- improvements, but mostly at the expense of using more memory. Unix has had a benefit from introducing virtual memory, which was present in VMS from the start. A major difference is that the Unix virtual memory does well on heavily loaded systems compared to VMS, with its ridiculous working-set system. Then Unix has had a breakthrough in disk-I/O with the Berkeley fast file system, etc, etc. I think Unix has passed the saturation point of vast improvements, and performance is going down too, unless one adds memory. (remember the complaints from people who supported 40 users on a 780 with BSD 4.1 and could only support 10 with BSD 4.2?) Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
sommar@enea.se (Erland Sommarskog) (01/10/89)
Seems like another OS war is blowing up... I just say this this time, based on my own experience. Some very subjective and unfair comparisons. The machine I writing this on is VAX780 running 4.3 BSD. The editor I'm using is Emacs. There doesn't need to be much load, until I notice a significant delay in such simple things as just echoing a character. Ah, Emacs, you say. True. But I tried vi for fun, and I wasn't free from that there either. My daily work I do in a VMS cluster on a 8530 (I believe). There I use TPU. These machines are heavy loaded, yet I almost never notice delays while editing. It should be added the bottle-necks are discs and to some extent memory, which I can notice when exit the editor and write the file. That can take time, due to fragmentation and not too many free blocks. A 8530 vs. a 780 is not fair, but my first impression when I started using this machine was that with 20 users this was just as slow the VMS 780 I was used to from the university when it had 50 users. (VMS V3.) Finally, the OS itself may slow down with the years, but since it adds more functionality, you still get the job done faster. -- Erland Sommarskog ENEA Data, Stockholm This signature is not to be quoted. sommar@enea.se
sloane@kuhub.cc.ukans.edu (Bob Sloane) (01/12/89)
In article <12938@steinmetz.ge.com>, davidsen@steinmetz.ge.com (William E. Davidsen Jr) writes: >[lots of stuff comparing VMS and UNIX deleted] > > I still see no reason to think that non-portable operating systems are > inherently faster or smaller than UNIX. ... > I have been looking for a portable operating system for some time. Does anyone know of one? Unix? Which version? BSD, SYS V, Ultrix, XENIX,...? Does such a thing really exist? I mean one operating system that can run on several different machines, UNCHANGED. While unix has been *modified* to run on quite a few different pieces of hardware, I am not convinced that it is "portable" and that VMS is "non-portable." What do you consider portable versus non- portable? +-------------------+-------------------------------------+------------------+ | Bob Sloane \Internet: SLOANE@KUHUB.CC.UKANS.EDU/Anything I said is | | Computer Center \ BITNET: SLOANE@UKANVAX.BITNET / my opinion, not my | | University of Kansas\ AT&T: (913) 864-0444 / employer's. | +-----------------------+-----------------------------+----------------------+
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (01/12/89)
In article <1472@cps3xx.UUCP> rang@cpswh.cps.msu.edu (Anton Rang) writes: | There is a lot of process creation overhead in VMS. On the other | hand, you don't need to create a process every time you do anything | (as UNIX does). In fact, most "basic" users (edit/compile/link) will | log in and use only their one process (or maybe two, if they have a | background editing process). I talked to a few VAX support people again, and they agree about process creation. Unfortunately VMS does what's called "image activation" which still results in reading a program from disk, establishing an environment (in the VMS sense) and all the things UNIX calls a subprocess, except accounting. This happens when you start the editor, compiler, linker, run the program, etc. It still isn't cheap in terms of system resources. | The file I/O overhead is significantly more than UNIX's if you're | working with only sequential files--in particular, sequential text | files. Against this, balance the capabilities of indexed files. If | you have an application working with large indexed files, VMS gives | you much more flexibility than UNIX (which hasn't even GOT indexed | files, and won't let you control disk allocation if you want to make | them up yourself). Do you have figures proving that VMS ISP is faster than database access using hash or B+tree methods in UNIX? I don't have any figures, but programs running in both environments seem to take about the same real time per transaction on an unloaded system. I certainly never found the need for having the user control disk allocation. I have always felt that fancy stuff should be in the programs using them, not in the O/S. With SysV shared libraries there is not penalty for having the library included in each program, a concept which is known as "shared global libraries" in VMS. I still see no reason to think that non-portable operating systems are inherently faster or smaller than UNIX. They *can* provide many more features which may be useful to some applications, and which are useful, if for no other reason than to lock applications to that vendor. Note that DEC is not using VMS on their new RISC machine. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (01/13/89)
In article <12938@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >In article <1472@cps3xx.UUCP> rang@cpswh.cps.msu.edu (Anton Rang) writes: >| There is a lot of process creation overhead in VMS. On the other >| hand, you don't need to create a process every time you do anything >| (as UNIX does). In fact, most "basic" users (edit/compile/link) will >| log in and use only their one process (or maybe two, if they have a >| background editing process). > > I talked to a few VAX support people again, and they agree about >process creation. Unfortunately VMS does what's called "image >activation" which still results in reading a program from disk, >establishing an environment (in the VMS sense) and all the things UNIX >calls a subprocess, except accounting. This happens when you start the >editor, compiler, linker, run the program, etc. It still isn't cheap in >terms of system resources. The image activation overhead is tiny compared to the process creation overhead. Image activation is like process creation on a UN*X system-- cheap and fast. Process creation, on the other hand, is miserably expensive under VMS. I tend to think that the process creation overhead is a bigger problem than previous posters have admitted. Many of the attempts by DEC (and third parties) to improve the VMS user interface and functionality use subprocesses. Send/edit in mail spawns a subprocess (or calls one of the callable editors, which is cheaper). The debugger now tries to spawn a subprocess (in the latest release). MMS spawns a subprocess. Subprocesses are being used more and more, and, on a loaded system, it really shows. An 8600 makes a great one or two-user system, but put any more on it, and the process creation overhead starts to get very annoying. I expect this problem to get worse as DEC implements more advanced user interfaces under VMS. DEC will probably be at least one step behind companies like Apollo in user interface design for the foreseeable future, and I think the process creation overhead is a major reason for this. (I could also go on about DECNET network overhead, but that's a bit off the topic.) -Dan Riley (dsr@lns61.tn.cornell.edu, dsr@crnlns.bitnet) -Wilson Lab, Cornell U.
hascall@atanasoff.cs.iastate.edu (John Hascall) (01/13/89)
In article <12938@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: [.... much ado about OS speed ....] > Note that DEC is not using VMS on their new RISC machine. No kidding? Since it uses a MIPS CPU+FPU and since VMS is (mostly) written in VAX-11 assembler and BLISS-32 ... isn't that obvious? John Hascall > bill davidsen (wedu@ge-crd.arpa) > {uunet | philabs}!steinmetz!crdos1!davidsen
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/13/89)
In article <2862@kuhub.cc.ukans.edu> sloane@kuhub.cc.ukans.edu (Bob Sloane) writes: >I have been looking for a portable operating system for some time. Does anyone >know of one? Unix? Which version? BSD, SYS V, Ultrix, XENIX,...? Almost any version. If you have reasonable hardware SVR4.0 may be your best bet, since it starts out already running on several widely different architectures, implying that many of the porting problems have been brought under control, and provides essentially a superset of the other variants. Xenix was merged into SVR3.2. Some people would prefer to port Mach, as Next has done. For toy computers it may be easier to port Minix or XINU. 4.3BSD has been ported more than once. >I mean one operating system that can run on several different machines, >UNCHANGED. Oh, get real! What do you think an operating system DOES, anyway? >While unix has been *modified* to run on quite a few different pieces >of hardware, I am not convinced that it is "portable" and that VMS is >"non-portable." "Portability" is relative, not absolute. UNIX (or, according to some Bell Labs staff, "Unix"; definitely not "unix") can be and has many times been ported to new, considerably different environments with far less work than a total reimplementation would have called for. That has not been demonstrated for VMS, for reasons that are obvious to most.
sloane@kuhub.cc.ukans.edu (Bob Sloane) (01/13/89)
In article <9360@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > "Portability" is relative, not absolute. UNIX (or, according to some > Bell Labs staff, "Unix"; definitely not "unix") can be and has many > times been ported to new, considerably different environments with far > less work than a total reimplementation would have called for. That > has not been demonstrated for VMS, for reasons that are obvious to most. I guess I should put more smiley faces in the stuff I post. I was just trying to point out that there are about a zillion different "uNiX's" and, as far as I can tell, all of them are incompatible with all of the others in some way or other. I really don't want to start another OS war. +-------------------+-------------------------------------+------------------+ | Bob Sloane \Internet: SLOANE@KUHUB.CC.UKANS.EDU/Anything I said is | | Computer Center \ BITNET: SLOANE@UKANVAX.BITNET / my opinion, not my | | University of Kansas\ AT&T: (913) 864-0444 / employer's. | +-----------------------+-----------------------------+----------------------+
gregg@ihlpb.ATT.COM (Wonderly) (01/13/89)
From article <7172@batcomputer.tn.cornell.edu>, by riley@batcomputer.tn.cornell.edu (Daniel S. Riley): > In article <12938@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >>In article <1472@cps3xx.UUCP> rang@cpswh.cps.msu.edu (Anton Rang) writes: >>| There is a lot of process creation overhead in VMS. On the other >>| hand, you don't need to create a process every time you do anything >>| (as UNIX does). In fact, most "basic" users (edit/compile/link) will >>| log in and use only their one process (or maybe two, if they have a >>| background editing process). >> >> I talked to a few VAX support people again, and they agree about >>process creation. Unfortunately VMS does what's called "image >>activation" which still results in reading a program from disk, >>establishing an environment (in the VMS sense) and all the things UNIX >>calls a subprocess, except accounting. This happens when you start the >>editor, compiler, linker, run the program, etc. It still isn't cheap in >>terms of system resources. > > The image activation overhead is tiny compared to the process creation > overhead. Image activation is like process creation on a UN*X system-- > cheap and fast. Process creation, on the other hand, is miserably > expensive under VMS. I once had this feeling, but believe it actually depends on what kind of process you create. Using LIB$SPAWN is expensive because DCL is along for the ride. If you use SYS$CREPRC directly, you can rid yourself of a lot of bagage. > > I tend to think that the process creation overhead is a bigger problem > than previous posters have admitted. > ... > An 8600 makes a great one or two-user system, but put > any more on it, and the process creation overhead starts to get very > annoying. I was really annoyed by the response time of the 750 that I used to manage. There were a lot of people using TeX and others running compute bound fortran programs that manipulated huge arrays (Math and Stat department computer). I wrote a long term scheduler to run as a detached process. It watches state transitions, percent CPU utilization and uses the LOAD-AVERAGES driver to manipulate batch queues as things get busy. It separates the users into two groups, those at base prio 4 and those at base prio 5. When it determines that you are busy with the CPU, it will put you into the 4 group. When you become idle again it puts you back into the 5 group (login interactive base prio is 5). The granularity is set at 7 seconds which provides a very comfortable transition. With 3 people running CPU bound an interactive user can type SPAWN and get a subprocess instantaneously. If the user goes compute bound for too long, base priority will be adjusted accordingly. Facilities are available to adjust priorities unconditionally on a per process bases. I intended to put identifier controlled algorythms in, but never got the chance. > I expect this problem to get worse as DEC implements more advanced user > interfaces under VMS. DEC will probably be at least one step behind > companies like Apollo in user interface design for the foreseeable > future, and I think the process creation overhead is a major reason > for this. (I could also go on about DECNET network overhead, but that's > a bit off the topic.) Some major reasons for the short falls in performance are: 1) QUANTUM==20 is too long, try 15 or 10 and you will see a marked change in response times. 2) I/O boosts and most other related priority manipulations by VMS are too short sighted. I.E. a priority boost of 1 is lost for each quantum that is completed without surrendering the CPU. To begin with, priority boosts are not necessary if compute bound process are degradated properly. -- Gregg Wonderly DOMAIN: gregg@ihlpb.att.com AT&T Bell Laboratories UUCP: att!ihlpb!gregg