mhobson@potpourri.UUCP (Marshall Hobson) (05/02/87)
in article <3492f966.8be4@apollo.uucp>, jps@apollo.uucp (Jeffrey P. Snover) says: > >>I need to obtain performance figures to compare bsd unix >>and dec's vms. I will apreciate if anyone can send me >>that kind of data (and to which I can make a reference...) > > You'll probably get a couple of hundred responses in this > vein but here's the first one: > > It depends on what you want to do. > > examples: > - If you want to spawn many jobs, bsd would probably > win hands down. > - If you want optimal performance on a system that > has heterogenous computing tasks (ya know, somebody > is calculating an fft, while someone else does a > db query while the secretary types a letter) you'll > find that vms will tend to be better. > > There probably about a million of examples so if you could > narrow you focus you'll probably get some better feedback. > > /*** OPINION ON ***/ > On of the great things about VMS is that (in general) if you > have enough money (and that might be alot) you can buy the > performance that you need. On the other hand > it doesn't matter how much money you have, you can't put > UNIX in a situation where it matters whether it works or not. Jeffrey, I have been using Gould's 'UTX/32' version of UNIX, and it's not only got (bsd)-Unix incorporated with-in it, but it also has AT&T-system V commands too! To my knowledge not only is the UNIX- better, but also Goulds machines are much faster too! ( about 25%) Also I believe it's about 25% cheaper( the hardware that is ) When I say faster and cheaper, I'm comparing to 'Dec's machines, and 'Dec's UNIX 'vms'. If there are any other user's of GOULD's - machines out-there in net-land I would really like to hear what they think about them too! Send me mail and let me know any particulars you want to know about Goulds machines/operating-systems! ##### Gould Computer Systems Division ### in Sunny South Florida ##### ##### ##### #### ...mcnc!rti-sel!gould!potpourri!mhobson ##### ##### ### ##### The opinions expressed are my own.(Probably!) In this case the Opinions stressed above, Are Probably those of my employer's too!8-)
lm@cottage.WISC.EDU (Larry McVoy) (05/02/87)
In article <259@potpourri.UUCP> mhobson@potpourri.UUCP (Marshall Hobson) writes:
*) I have been using Gould's 'UTX/32' version of UNIX, and it's
*) not only got (bsd)-Unix incorporated with-in it, but it also has
*) AT&T-system V commands too! To my knowledge not only is the UNIX-
*) better, but also Goulds machines are much faster too! ( about 25%)
*) Also I believe it's about 25% cheaper( the hardware that is ) When
*) I say faster and cheaper, I'm comparing to 'Dec's machines, and
*) 'Dec's UNIX 'vms'. If there are any other user's of GOULD's -
Uhh, excuse me? "Dec's UNIX 'vms'"? Uhh, sorry ace, but VMS is not UNIX.
VMS is a proprietary OS written by DEC for Vaxen in bliss, I believe. I
think you are referring to Ultrix.
Also, you don't know your machine very well. It's not 25% faster than a
garden variety Vax 780, it's about 1000% faster (Powernode == 10 mips over
2 processors, I think).
---
Larry McVoy lm@cottage.wisc.edu or uwvax!mcvoy
"What a wonderful world it is that has girls in it!" -L.L.jps@apollo.uucp (Jeffrey P. Snover) (05/04/87)
>I need to obtain performance figures to compare bsd unix >and dec's vms. I will apreciate if anyone can send me >that kind of data (and to which I can make a reference...) You'll probably get a couple of hundred responses in this vein but here's the first one: It depends on what you want to do. examples: - If you want to spawn many jobs, bsd would probably win hands down. - If you want optimal performance on a system that has heterogenous computing tasks (ya know, somebody is calculating an fft, while someone else does a db query while the secretary types a letter) you'll find that vms will tend to be better. There probably about a million of examples so if you could narrow you focus you'll probably get some better feedback. /*** OPINION ON ***/ On of the great things about VMS is that (in general) if you have enough money (and that might be alot) you can buy the performance that you need. On the other hand it doesn't matter how much money you have, you can't put UNIX in a situation where it matters whether it works or not.
wagner@iaoobelix.UUCP (05/07/87)
> /***** iaoobelix:comp.unix.ques / apollo!jps / 5:44 am Apr 30, 1987*/ > It depends on what you want to do. > > examples: > - If you want to spawn many jobs, bsd would probably > win hands down. This might (:-) come from the fact that UNIX essentially is based upon the easy process creation scheme. Everything (almost...) runs in a seperate process: I won't try this under the VeryMysteriousSystem. > - If you want optimal performance on a system that > has heterogenous computing tasks (ya know, somebody > is calculating an fft, while someone else does a > db query while the secretary types a letter) you'll > find that vms will tend to be better. I haven't seen actual benchmarks of this kind yet. It also seems to be very difficult to get objective data! Maybe you're right if you are thinking of VAXen running UNIX and the same machines running VMS. From my experiences with a VAX/750 (UNIX) and Suns (3/50 and 3/260) the 750 is about the factor 6 to 15 *slower* than the Sun 3/260. A VMS VAX/750 needs some more time (factor 8 to 20). These results are based on the compilation time and on some simple benchmarks with CProlog1.5. Note that the source code was approximately the same on all machines and operating systems. BTW, another feature of UNIX makes it much more friendly than VMS: pipelines. Have you ever tried to do such thing as cat *.icon | convert-to xerox | pretty-print | send-to-dlion or enter -f jw_utils `cat jw_tools.h | sed 's/"//; s/".*/\ \\\/; $ s/\\\//'` under VMS?? Be careful not to mix up all these temporary files... My personal view of UNIX compared to VMS is approximately the following: UNIX is likes a sports car, many knobs (including dangerous ones) but as soon as you know how to operate this beast..., well! VMS is like a tractor, a somehow simple and robust tool for heavy work. In principle, I believe UNIX is a more adequate operating system for research (esp. AI research) because of its higher developed facilities as far as the (nested) shell philosophy is concerned, and because of its modular structure, e.g. allowing for pipelines of commands. However, for commercial and industrial applications VMS might (MIGHT) be more advantagous due to its real-time properties and robust design. Juergen Wagner, (USENET) ...seismo!unido!iaoobel!wagner ("Gandalf") Fraunhofer Institute IAO, Stuttgart # include <disclaimers/vanilla.h> FOO_M_S$ FLAME/INPUT=[NET.LAND]/OUTPUT=NLA0:
rick@potpourri.UUCP (Rick Schneider) (05/12/87)
in article <3517@spool.WISC.EDU>, lm@cottage.WISC.EDU (Larry McVoy) says: > > ... It's not 25% faster than a > garden variety Vax 780, it's about 1000% faster (Powernode == 10 mips over > 2 processors, I think). > > --- > Larry McVoy lm@cottage.wisc.edu or uwvax!mcvoy > > "What a wonderful world it is that has girls in it!" -L.L. To set the record a little straighter.... 1. UTX/32 version 2.0 is BSD 4.3/System V selectable. 2. The Powernode (PN) series comes in various configurations ranging from under 1 mip to a little over 8 mips (depending upon which processor is bought [PN6xxx or PN9xxx]) 3. The PN6080 and PN9080 have two processors, a CPU/IPU configuration. The IPU is a CPU but runs in a master/slave orientation. 4. A PN6031 (stripped down model) is equivalent to a VAX 11/780 in speed at less than 1/2 the price. 5. As far as cost goes, a PN9080 runs at about the same speed as a VAX 8800 at less than 1/2 the price. 6. If you are really interested in a "fire-breather", try the latest product, NP1. NP1 is a true dual processor running at approx 18 mips. The cost is somewhere around $400,000. As far as VMS goes, I've used both it and UNIX extensively. As a programmer, I'd say UNIX is the hands down winner for a multi-programmer environment. If you are talking about speed on a VAX, VMS is the faster of the two. VMS was written to take advantage of VAX hardware where as UNIX was not. In any benchmark I have run on VAXen, VMS has run applications about 1.5 times faster then the same application running on UNIX (VAX environment). On a PN9080, applications run 5.6 times greater than the same application running on a VAX 11/780 running VMS. Both statements are considering only CPU time, not real time. Of course the real time ratios will differ considerably depending on the load placed on either system. -- Rick Schneider ...{akgua!ucf-cs!novavax,mcnc!rti-sel}!gould!rschneider GOULD CSD - in the cultural wasteland of sunny Ft. Lauderdale, Florida The opinions expressed are not those of my employer or are they?
ndd@duke.cs.duke.edu (Ned Danieley) (05/13/87)
In article <294@potpourri.UUCP> rick@potpourri.UUCP (Rick Schneider) writes: ... >4. A PN6031 (stripped down model) is equivalent to a VAX 11/780 > in speed at less than 1/2 the price. >5. As far as cost goes, a PN9080 runs at about the same speed as a > VAX 8800 at less than 1/2 the price. ... >-- >Rick Schneider ...{akgua!ucf-cs!novavax,mcnc!rti-sel}!gould!rschneider >GOULD CSD - in the cultural wasteland of sunny Ft. Lauderdale, Florida >The opinions expressed are not those of my employer or are they? At less than half the price, BUT: so far as I know, no one other than Gould makes boards for the SELBUS, which makes adding equipment rather pricey. As an example, we recently bought a couple of 2 Meg memory boards, on sale, for $6000 each. On the other hand, it seems like everyone makes boards for the UNIBUS, and sells them more cheaply than DEC. Ned Danieley
preece@ccvaxa.UUCP (05/15/87)
lm@cottage.WISC.EDU (Larry McVoy): > Also, you don't know your machine very well. It's not 25% faster than a > garden variety Vax 780, it's about 1000% faster (Powernode == 10 mips over > 2 processors, I think). ---------- I don't know what Marshall's machine is, but a single-processor 6000 would be 25-50% faster than a 780, depending on application. -- scott preece gould/csd - urbana uucp: ihnp4!uiucdcs!ccvaxa!preece arpa: preece@gswd-vms (preece@claudius.Gould.com, if it's gotten h ith ith
landauer@sun.uucp (Doug Landauer) (05/21/87)
This is mostly about VMS -- if there are any followups, please send them to comp.os.vms. In article <667@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >In article <3583@jade.BERKELEY.EDU> steven@pearl.berkeley.edu (Stephen the >Greatest [or so he claims]) says this about VAX/VMS: >> ...Also, I hate the shell (or command inter- >>pretor) in VMS. Why can't anybody in DEC write something like C-Shell? >>I think VMS is absolutely able to support a C-Shell-like command interface. Stephen is right -- VMS can indeed support shell-like interfaces. Several VMS software packages exist which are Unix-lookalike systems: Eunice, from The Wollongong Group; VMS/Workbench (or whatever they call it these days), from Interactive Systems; something whose name I forgot, from HCR (sorry), and at least a couple others. Even DEC sells something called the DECshell, which runs on VMS. I don't know which shell(s) it looks like, but I've heard it can ease somewhat the pain of working with VMS. >VMS is not able to support a C-Shell-like command interface for a rather >important reason. The UNIX shell interface depends heavily on process >creation and many commands create several processes. VMS can support shell-like user interfaces just fine. They are just slower than DEC's own CLI ("Command Line Interpreter", or "Command Language Interpreter", I forget which) because of the way DEC's CLI invokes images, and because, as you say, >VAX/VMS is extremely inefficient at creating new processes. [ There is an ambiguity in the term "DCL" -- many VMS users use "DCL" to mean the CLI, but it really means the language ("DEC Command Language") that the CLI interprets. I'll use "the CLI" to mean DEC's CLI for VMS.] >When the >VMS command interpreter executes a user program, it does not create a >new process, but simply does the equivalent of a UNIX exec() system >call. Thus the current invocation of the command interpreter >effectively dies and is replaced by the user program. (How it regains >control after the user program terminates is a long, long story that >I don't fully understand.) The two true statements made in the above paragraph are "it does not create a new process" and "[Rahul doesn't] fully understand". The CLI regains control because it did not die and was not replaced by the user program. The CLI normally lives in what DEC calls "P1" space. Think of the VAX address space as being divided in four parts: P0, P1, S0 and S1. P0 is your user program space, P1 is for the CLI, and the S spaces (I'm not sure whether S1 exists) are where the VMS kernel lives. When the CLI starts up a command, it does so with an "IMAGE ACTIVATION" system call -- this reads the command into P0 space and lets it start running. More evidence that it is still around is in the awful interface that they implemented for parsing DCL-style command qualifiers. (How it does that is a long, long story that would cause me to puke before I got finished explaining it.) >The above does not prevent DEC from providing a structured shell >programming language. However, the command language (modestly named >DEC Command Language) appears to have a batch environment as its design >basis, and has very little "memory" of past statements executed. In a >batch enviroment, where each control card is separately interpreted, it >is difficult to provide control structures such as >if..then..else...endif, while and for loops, etc. > >More evidence that DCL has little or no memory: there is no way of >giving multiple commands on the same line. This is just circumstantial evidence, and your conclusion is totally wrong. What we need here is a little historical perspective. My conclusion from the same evidence is that the design of DCL simply showed a lack of foresight on DEC's part (they underestimated how successful the VAX would be, and how successful Unix would be on it, and overestimated the continued importance of the PDP-11), and a "foolish consistency" -- one design goal was that command interpreters which understand DCL had to run on PDP-11-sized machines, and I suspect that they decided that putting in too fancy a command language would prevent such interpreters from being feasible on such small machines. >To properly handle multiple >commands, the command interpreter would have to save the previous >partially-executed command line somewhere. But since the command >interpreter effectively does an exec() each time it executed a user >command, it can't save information and reuse it very easily--the >next command is really executed by a brand-new invocation of the >command interpreter. > >I am only speculating here, ... ... "here" being your whole article ... > ... but I haven't heard any better explanations >of why DCL is oriented towards a one-command-one-line-only-no-control- >structures command interface. Look at it from DEC's point of view at the time that DCL was designed: the PDP-11 was the single most successful computer (in terms of units shipped) in the history of computing. [ or damn close -- anyone know for sure? ] DEC *had* to continue to support it. They had gone through an awful fiasco on the PDP-11 where DEC themselves sold *five* different operating systems for that machine (maybe more -- let's see, DOS, RT-11, RTOS, RSX-11M, and RSX-11D which became IAS). And to the great chagrin of their in-house OS programmers, there were as many PDP-11s running Unix as were running some of their own operating systems. DEC needed some consistency at that point. The motivation for designing DCL was to prevent something like that from happening on the VAX, without abandoning their enormous installed base of PDP-11 users. They wanted a single OS to be dominant on the VAX line, and at that they've been almost totally successful. [I don't know the exact numbers, but I think that about 80% or 90% of all VAXen run VMS.] Of course, they finally had to give in and lend some token support to a version of Unix, but they're certainly in a better position now than they were with the PDP-11. It's hard for people who weren't in the field then to see how important the PDP-11 was to DEC before the VAX came out. Don't get me wrong -- I hated it when I had to program on VMS, and I hated DCL. However, it's good enough for who it's for, and it was designed a decade ago, in a very different world. -- Doug Landauer Sun's network: landauer@morocco Phone: 415 354-4747 ARPA Internet: landauer@sun.com UUCP: {amdahl, decwrl, hplabs, seismo, ...}!sun!landauer Disclaimer -- I have never worked for DEC, but have worked with DEC machines (off and on) for the past 15 years.
steven@pearl.berkeley.edu (Stephen the Greatest) (05/21/87)
Yeah. I always wonder why VMS cannot handle multiple commands on one single line. I guess that it has something to do with its internal design. Being in Berkeley, I can say that I *love* BSD UNIX, but there are things I will criticize on. For example, a lot of BSD features are kinda *hacked*, or added on later, instead of being a part of the original design. VMS is more structured and consistent. But still, I think BSD UNIX is far superior to VMS (and also System V). - Stephen
ram@nucsrl.UUCP (06/01/87)
This is not in response to the above note but an observation on UNIX.
The option(s) list flagging in the command line is probably the
most inconsistent thing that I have seen. The variants include
1. Some need a white space after the option if they require a
filename or some string of characters and some do not.
i.e. -l<filename> may not work when -l <filename> is expected
and vice-versa
2. Rarely one notices that the option don't have "-" prefixed.
Like in "tar rvf".
-------------------
Renu Raman UUCP:...ihnp4!nucsrl!ram
1410 Chicago Ave., #505 ARPA:ram@eecs.nwu.edu
Evanston IL 60201 AT&T:(312)-869-4276 kai@uicsrd.UUCP (06/05/87)
You forgot to mention that some programs want options separated,
with values immediately following (eg. lpr -Pprinter -J "job"
file) and some want the options all together and the values all
following (eg. dump 0unsdbf 2200 6250 20 /dev/rxt00h).
The problems you describe and those above have to be expected
when utilities are written (and converted) by many different
people using many different version of UNIX, with no set
guidelines to follow (unlike DEC's VAX/VMS - now THOSE are
strict guidelines).
Hence the popularity of the public domain getopt routines
floating around in comp.sources.{misc,unix} . Getopt allows you
to specify all of the above style options. Sure works nice, and
makes programming a little easier.
Of course this doesn't help with those programs already written.
You might spend years converting them, and then move to another
site, and have to do it all over again.