Path: gmdzi!unido!mcsun!uunet!aplcen!uakari.primate.wisc.edu!
zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!news-server.csri.toronto.edu!
utgpu!watserv1!maytag!watdragon!watsol.waterloo.edu!tbray
From: tb...@watsol.waterloo.edu (Tim Bray)
Newsgroups: comp.arch
Subject: Unix Filesystem Benchmark Results (long)
Message-ID: <1990May13.165810.26723@watdragon.waterloo.edu>
Date: 13 May 90 16:58:10 GMT
Sender: dae...@watdragon.waterloo.edu (Owner of Many System Processes)
Organization: University of Waterloo
Lines: 646
Posted: Sun May 13 17:58:10 1990
Howdy folks. We've been hacking text databases here on the New OED project
for years, and have been disappointed at the performance of Unix filesystems
in general, and also at the tools available for measuring that performance.
So I wrote a program to address this need. It fails to meet the SPEC
criterion of being real working code that does something useful, but it does
produce very interesting numbers, most of which I believe.
This posting includes a summary of the results of running the benchmark on all
the machines I could get my hands on, some subjective commentary, and the
source code for the benchmark, the comments in which should be read by
everyone before beginning to think about believing these numbers.
Cheers, Tim Bray, Open Text Systems, Waterloo, Ont.
-------Sequential Output-------- ---Sequential Input-- --Random-
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--
K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
DEC 5810 330 73.6 690 62.8 195 29.0 274 61.6 649 45.9 27.7 4.9
434 92.7 732 63.3 206 29.2 382 80.7 701 47.6 34.3 5.1
418 88.1 718 65.0 196 28.7 386 81.7 744 52.3 27.1 5.8
MipsM/2K 316 35.2 381 8.8 302 11.4 611 67.9 1369 27.4 28.5 1.2
345 38.1 435 10.0 226 8.8 399 44.1 876 17.3 21.3 1.3
362 40.0 440 10.5 371 15.0 785 89.1 1762 37.3 26.4 1.8
NeXT 243 92.0 352 48.8 210 38.9 217 95.0 782 72.4 28.4 12.7
243 92.9 360 50.0 216 40.7 251 95.8 773 71.4 28.7 14.3
245 93.1 346 48.2 215 40.3 218 95.7 777 71.3 26.7 13.7
Seq.Symm. 178 99.1 951 90.7 307 48.1 151 95.7 694 57.2 35.6 6.6
176 98.2 926 85.8 285 43.4 150 95.4 655 51.5 33.4 6.7
VAX 8650 197 81.7 262 22.3 116 14.1 255 81.5 434 16.6 22.1 2.5
186 77.7 214 18.6 99 12.7 144 46.9 361 15.1 16.8 2.2
Sun 4/260 298 83.2 791 58.2 296 26.3 312 94.5 840 44.8 ****
328 92.6 796 59.7 288 26.4 298 91.2 726 39.7 ****
386 229 91.9 241 27.5 207 46.4 209 91.9 437 56.0 34.4 7.0
IBM R 6000 654 89.0 1178 22.6 434 13.1 750 94.2 1539 20.9 39.6 3.0
712 96.5 1258 24.1 444 13.4 727 91.3 1546 21.7 33.7 2.3
Commentary: feel free to disbelieve
DEC 5810: Ultrix 3.1C-0 (Rev 42), 1.2G filesystem on disk, 91% full.
The R2000 in here is slower than the R3000 in the Mips M/2K, but the
I/O rates are competitive; however this box has to burn more CPU to
achieve those rates. Note that block input and output are about the
same speed, making it slower than the MIPS on input but faster on
output.
Mips M/2000: UMIPS 4.0, 564M filesystem on MIPS disk, 83% full.
This is a very fast CPU, and it shows in the %CPU columns. The
block-mode input number is very good - over 1.25 effective
megabytes/sec off the disk. Note the block-in vs. block-out anomaly
with respect to the DEC machine. Also, the seeks/sec. are unexciting.
NeXT: SW Version 1.0, 446M filesystem on NeXT HD, 82% full.
One of the slower CPUs in the crowd, and it shows. Given its price
relative to some of these other boxes, this is excellent performance;
the NeXT is supposed to have fancy DMAs. Didn't have an optical I
could write on, but that would be very interesting.
Sequent: 10 386 processors, Dynix 3.0.17.9, 564M filesystem, 82% full.
The individual processors in here are fairly-slow 386es, and that shows
in the %CPU column. But burning 100% of a 386 to do the filesystem and
leaving the other 9 to do useful work seems smart to me. The block I/O
throughput and in particular the seeks/second are very good. Looks
like a good database machine.
VAX 8650: 4.3bsd, 584M filesystem on CDC Wren VI on UDA, 33% full.
Well, the myth of VAX as good I/O machine seems to be biting the dust
here. An 8650 is a pretty fast CPU, and has an elaborate I/O
architecture. There must be a bottleneck here - candidates are the
UDA, the Unibus, and 4.3bsd. Note the %CPU figures are very
low, which may just be a result of the I/O being so slow, or some CISC
artifact. It's even slow at seeking. Seven years ago, we used to have
some 780s with RP07's on MASSBUSes - I wouldn't be surprised if they
measured faster than this.
Sun 4/260: SunOS 4.0.3, 526M filesystem on Fuji M2344, 87% full.
Not bad, consistently in the top half. Some of the speed seems to be
purchased by burning CPU - the %CPU figures are quite high. Couldn't
get meaningful numbers on seeks/sec because we don't have the disk
space to spare. With 32M of memory, operating on a 50M file, the
caching drove the seeks/sec up over 60.
386: 20 MHz AMI motherboard, 386/ix V2.0.2, 180M filesys on MaxStor ESDI
disk, 51% full.
I think this is pretty damn good performance for a machine which is
an order of magnitude less in cost than some of the other boxes here.
In particular, its random I/O performance seems to rival that of the
big RISC chips, both the DEC and MIPS implementations (8M memory for a
50M file, so it ain't caching much). The scuttlebutt says that these
can be made still faster using caching controllers.
IBM R6000, Beta Test AIX, 450M filesystem on "Cheap SCSI", 34% full.
Was never able to run the tests on an idle system, something was
burning CPU all the time, if vmstat(1) is to be believed, but I
couldn't find a candidate using ps(1) - except perhaps something called
"kproc", but that sounds like a fake kernel task. Also, there was only
about 50 Mb free on the filesystem, so the sysadmin did something with
"logical volumes" and the "chfs(1)" command then the filesys was 250M
bigger - might this be muddying the waters? A test run before the chfs
showed *unbelievable* rates, like 5+ Mb system coming off the filesys
using read(2). Anyhow, the conclusion is clear - this puppy is an
I/O monster.
Code
Path: gmdzi!unido!mcsun!uunet!aplcen!samsung!cs.utexas.edu!rutgers!cbmvax!
snark!eric
From: e...@snark.uu.net (Eric S. Raymond)
Newsgroups: comp.arch
Subject: Re: Unix Filesystem Benchmark Results (long)
Message-ID: <1WQxyF#1PgpgZ6rsnj60x8CW32qY30d=eric@snark.uu.net>
Date: 14 May 90 14:44:37 GMT
References: <1990May13.165810.26723@watdragon.waterloo.edu>
Lines: 17
Posted: Mon May 14 15:44:37 1990
Back-References: <23...@bellcore.bellcore.com> <12...@stag.math.lsa.umich.edu>
In <1990May13.165810.26...@watdragon.waterloo.edu> Tim Bray wrote:
> [in an article listing lots of file system benchmarks]
> 386: 20 MHz AMI motherboard, 386/ix V2.0.2, 180M filesys on MaxStor ESDI
> disk, 51% full.
> I think this is pretty damn good performance for a machine which is
> an order of magnitude less in cost than some of the other boxes here.
> In particular, its random I/O performance seems to rival that of the
> big RISC chips, both the DEC and MIPS implementations (8M memory for a
> 50M file, so it ain't caching much). The scuttlebutt says that these
> can be made still faster using caching controllers.
Mene, mene, tekel, uparshin! This is why the `workstation' market as we've
known it is doomed -- these machines are getting better faster than the
Suns and HPs and Irises out there, they run more software, and they're *much*
cheaper. No one will survive the attack of the killer LOW END micros!
--
Eric S. Raymond = ...!uunet!snark!eric (mad mastermind of TMN-Netnews)
Path: gmdzi!unido!mcsun!uunet!maverick.ksu.ksu.edu!zaphod.mps.ohio-state.edu!
swrinde!cs.utexas.edu!texbell!texsun!newstop!sun!snafu!lm
From: l...@snafu.Sun.COM (Larry McVoy)
Newsgroups: comp.arch
Subject: Re: Unix Filesystem Benchmark Results (long)
Message-ID: <135710@sun.Eng.Sun.COM>
Date: 15 May 90 02:44:40 GMT
References: <1990May13.165810.26723@watdragon.waterloo.edu>
<1WQxyF#1PgpgZ6rsnj60x8CW32qY30d=eric@snark.uu.net>
Sender: n...@sun.Eng.Sun.COM
Reply-To: l...@sun.UUCP (Larry McVoy)
Organization: Sun Microsystems, Mountain View
Lines: 37
Posted: Tue May 15 03:44:40 1990
In article e...@snark.uu.net (Eric S. Raymond) writes:
>In <1990May13.165810.26...@watdragon.waterloo.edu> Tim Bray wrote:
>> [in an article listing lots of file system benchmarks]
>> 386: 20 MHz AMI motherboard, 386/ix V2.0.2, 180M filesys on MaxStor ESDI
>> disk, 51% full.
>> I think this is pretty damn good performance for a machine which is
>> an order of magnitude less in cost than some of the other boxes here.
>> In particular, its random I/O performance seems to rival that of the
>> big RISC chips, both the DEC and MIPS implementations (8M memory for a
>> 50M file, so it ain't caching much). The scuttlebutt says that these
>> can be made still faster using caching controllers.
>
>Mene, mene, tekel, uparshin! This is why the `workstation' market as we've
>known it is doomed -- these machines are getting better faster than the
>Suns and HPs and Irises out there, they run more software, and they're *much*
>cheaper. No one will survive the attack of the killer LOW END micros!
>--
> Eric S. Raymond = ...!uunet!snark!eric (mad mastermind of TMN-Netnews)
Yeah? Price out the following (what I consider to be the minimal interesting
configuration):
486 (at least 25 Mhz)
8 megs
400 megs of disk (at least 500 KB / sec sustained throughput)
Ethernet
19 inch 1k x 1k BW monitor
Mouse
Unix (including networking, compilers, window system).
I suspect that you are well over $10K. The last time I priced this stuff
I came up with about the same prices for similarly configured systems.
Now, if you don't want any memory, or window system, or networking...
---
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 l...@sun.com
Path: gmdzi!unido!mcsun!uunet!csinc!rpeglar
From: rpeg...@csinc.UUCP (Rob Peglar)
Newsgroups: comp.arch
Subject: Re: PCs v. WSs
Summary: Pricing? Here's an example.
Message-ID: <208@csinc.UUCP>
Date: 15 May 90 14:23:33 GMT
References: <1990May13.165810.26723@watdragon.waterloo.edu> <135710@sun.Eng.Sun.COM>
Organization: Control Systems, Inc., St. Paul MN
Lines: 58
Posted: Tue May 15 15:23:33 1990
> Yeah? Price out the following (what I consider to be the minimal interesting
> configuration):
>
> 486 (at least 25 Mhz)
> 8 megs
> 400 megs of disk (at least 500 KB / sec sustained throughput)
> Ethernet
> 19 inch 1k x 1k BW monitor
> Mouse
> Unix (including networking, compilers, window system).
>
> I suspect that you are well over $10K. The last time I priced this stuff
> I came up with about the same prices for similarly configured systems.
> Now, if you don't want any memory, or window system, or networking...
Well, here's an example from real life (I ought to know, I bought the
thing)
Intel 401 (486@25, 8MB 80ns) $ 7,550
Imprimis 94xxx-383 ESDI 1,400
DPT MX3011/70 512KB caching cont. 800
WD 8003E (EtherCard Plus) 200
Sony 16" 1kx768x16 (color) mon. 650
Paradise VGA 200
Microsoft serial 2-button 50
SCO ODT 1.0 900
-------
11,750
OK, so the monitor isn't 19" :-)
One could certainly shave hundreds off this configuration by using a stock
SCSI disk/controller pair, e.g. Adaptec 1542A w/ your favorite SCSI disk.
Is this "well over" $10,000? Your guess.
At least we don't have to pay four-digit figures for maintenance, another
hidden cost of operation that hardly anyone mentions. In the large
system world, this cost becomes overriding, to the point that entire
mainframe/supercomputers are scrapped in favor of newer models because
the maintenance cost alone justifies a new purchase.
Case in point, my local Sun rep is trying to push a $1,600 software
maintenance contract on me, for my two Sun 386i's. I'd even buy it,
if SunOS on the 386i would continue to be developed. My spies tell
me that 4.0.3 is the end; 4.1 doesn't support the 386i machine. True?
Note, the costs above are certainly less than "retail" (whatever that
means), so Joe Homeuser couldn't get these prices. Then again, he
couldn't get developer discounts on Suns, either :-)
Rob
> ---
> 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 l...@sun.com
Path: gmdzi!unido!mcsun!uunet!cs.utexas.edu!samsung!uakari.primate.wisc.edu!
uflorida!mephisto!ncar!ico!rcd
From: r...@ico.isc.com (Dick Dunn)
Newsgroups: comp.arch
Subject: Re: Unix Filesystem Benchmark Results (long)
Summary: why such a high-end *86?
Message-ID: <1990May15.205831.3841@ico.isc.com>
Date: 15 May 90 20:58:31 GMT
References: <1990May13.165810.26723@watdragon.waterloo.edu> <135710@sun.Eng.Sun.COM>
Organization: Interactive Systems Corporation, Boulder, CO
Lines: 14
Posted: Tue May 15 21:58:31 1990
l...@snafu.Sun.COM (Larry McVoy) writes:
> Yeah? Price out the following (what I consider to be the minimal interesting
> configuration):
>
> 486 (at least 25 Mhz)
> 8 megs
...[rest of wish list]...
Why a 486? That pushes the price up an awful lot (enough to make your
point, anyway:-), but it also puts you at a far higher performance level
than a lot of existing "workstations"...including, for example, Sun 3's.
--
Dick Dunn r...@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870
...If you plant ice, you're gonna harvest wind.
Path: gmdzi!unido!mcsun!uunet!wuarchive!zaphod.mps.ohio-state.edu!usc!apple!
sun-barr!newstop!sun!snafu!lm
From: l...@snafu.Sun.COM (Larry McVoy)
Newsgroups: comp.arch
Subject: Re: Unix Filesystem Benchmark Results (long)
Message-ID: <135780@sun.Eng.Sun.COM>
Date: 16 May 90 00:48:59 GMT
References: <1990May13.165810.26723@watdragon.waterloo.edu>
<135710@sun.Eng.Sun.COM> <1990May15.205831.3841@ico.isc.com>
Sender: n...@sun.Eng.Sun.COM
Reply-To: l...@sun.UUCP (Larry McVoy)
Organization: Sun Microsystems, Mountain View
Lines: 39
Posted: Wed May 16 01:48:59 1990
In article <1990May15.205831.3...@ico.isc.com> r...@ico.isc.com (Dick Dunn) writes:
>l...@snafu.Sun.COM (Larry McVoy) writes:
>> Yeah? Price out the following (what I consider to be the minimal interesting
>> configuration):
>>
>> 486 (at least 25 Mhz)
>> 8 megs
>...[rest of wish list]...
>
>Why a 486? That pushes the price up an awful lot (enough to make your
>point, anyway:-), but it also puts you at a far higher performance level
>than a lot of existing "workstations"...including, for example, Sun 3's.
Check out Wednesday's Wall Street Journal. Apparently we have a $5K
sparc box now. My wish list stays the same, the price just dropped by
a factor of 2.
Anyway, the 486 is just so that we get a pretty close mips rating. The
386 is a little on the slow end.
Now, for all those who are saying that Xenix + 386 is the way to go -
STOP! I agree that it is a nice environment (much preferable to a
3/50, for example, provide the networking is there). I ported
Lachman's TCP/IP to SCO Xenix. Within a week of getting the 386 box, I
moved from a 3/50.
But it's simply not a reasonable comparison - it's what we call apples
to oranges. I *need* a window system. Xenix is a pretty nice
approximation (if someone made a terminal that did that, I'd buy it for
home use), but it's not the same. Side by side windows are useful.
Networking is useful. Having a full Unix env is useful.
Bottom line is: they're different markets. Different users. Different
Unix. Until the machines differ only in cost, the argument is
pointless.
---
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 l...@sun.com
Path: gmdzi!unido!mcsun!uunet!samsung!sdd.hp.com!uakari.primate.wisc.edu!ark1!
nems!mimsy!mojo!SYS...@KING.ENG.UMD.EDU
From: sys...@KING.ENG.UMD.EDU (Doug Mohney)
Newsgroups: comp.arch
Subject: Re: Unix Filesystem Benchmark Results (long)
Message-ID: <00936C10.82850A60@KING.ENG.UMD.EDU>
Date: 16 May 90 12:39:34 GMT
References: <1990May13.165810.26723@watdragon.waterloo.edu>
<135710@sun.Eng.Sun.COM> <1990May15.205831.3841@ico.isc.com>,<135780@sun.Eng.Sun.COM>
Sender: n...@eng.umd.edu (The News System)
Reply-To: sys...@KING.ENG.UMD.EDU (Doug Mohney)
Organization: The U. of MD, CP, CAD lab
Lines: 11
Posted: Wed May 16 13:39:34 1990
In article <135...@sun.Eng.Sun.COM>, l...@snafu.Sun.COM (Larry McVoy) writes:
>Check out Wednesday's Wall Street Journal. Apparently we have a $5K
>sparc box now. My wish list stays the same, the price just dropped by
>a factor of 2.
>
>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
Apparently? You don't know ;-) ("I could tell you, but then I'd have to
kill you...")
Path: gmdzi!unido!mcsun!uunet!samsung!sdd.hp.com!zaphod.mps.ohio-state.edu!
ncar!ico!rcd
From: r...@ico.isc.com (Dick Dunn)
Newsgroups: comp.arch
Subject: Re: Unix Filesystem Benchmark Results (long)
Summary: the comparison still holds
Message-ID: <1990May16.203856.7384@ico.isc.com>
Date: 16 May 90 20:38:56 GMT
References: <1990May13.165810.26723@watdragon.waterloo.edu>
<135780@sun.Eng.Sun.COM>
Organization: Interactive Systems Corporation, Boulder, CO
Lines: 44
Posted: Wed May 16 21:38:56 1990
l...@snafu.Sun.COM (Larry McVoy) writes:
> [I wrote...]
> >Why a 486? That pushes the price up an awful lot ...
> Check out Wednesday's Wall Street Journal. Apparently we have a $5K
> sparc box now...
OK, good. Looks like a nice product, but it doesn't affect the issues.
>...Anyway, the 486 is just so that we get a pretty close mips rating. The
> 386 is a little on the slow end.
Rubbish. I've been using a 25 MHz 386 for some time now. It's plenty fast
enough for real UNIX with a window system. Note that Bray's article cited
testing on a 20 MHz 386.
> Now, for all those who are saying that Xenix + 386 is the way to go -
> STOP!...
Oh, stop yourself...who said anything about Xenix? You were following up
on an article in which the 386 system was running 386/ix, not Xenix.
>...But it's simply not a reasonable comparison - it's what we call apples
> to oranges...
Which, presumably, is *why* people weren't talking about Xenix.
>...I *need* a window system...
So *get* a window system. How about X? And you've got *lots* of displays
to choose from, at various tradeoffs in price, speed, and resolution.
> Bottom line is: they're different markets. Different users. Different
> Unix. Until the machines differ only in cost, the argument is
> pointless.
I think you're making up most of the differences. You don't need a 486.
Xenix is a straw man. If you want a window system, you can get it.
I *do* agree that the SLC looks like a very competitive machine for the
market.
--
Dick Dunn r...@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870
...If you plant ice, you're gonna harvest wind.
Path: gmdzi!unido!mcsun!uunet!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!
mips!winchester!mash
From: m...@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: Unix Filesystem Benchmark Results (long)
Summary: Be careful with such numbers
Message-ID: <38816@mips.mips.COM>
Date: 17 May 90 00:19:35 GMT
References: <1990May13.165810.26723@watdragon.waterloo.edu>
<1WQxyF#1PgpgZ6rsnj60x8CW32qY30d=eric@snark.uu.net>
Sender: n...@mips.COM
Lines: 82
Posted: Thu May 17 01:19:35 1990
In article <1WQxyF#1PgpgZ6rsnj60x8CW32qY30d=e...@snark.uu.net>, e...@snark.uu.net
(Eric S. Raymond) writes:
> In <1990May13.165810.26...@watdragon.waterloo.edu> Tim Bray wrote:
> > [in an article listing lots of file system benchmarks]
> > 386: 20 MHz AMI motherboard, 386/ix V2.0.2, 180M filesys on MaxStor ESDI
> > disk, 51% full.
> > I think this is pretty damn good performance for a machine which is
> > an order of magnitude less in cost than some of the other boxes here.
> > In particular, its random I/O performance seems to rival that of the
> > big RISC chips, both the DEC and MIPS implementations (8M memory for a
> > 50M file, so it ain't caching much). The scuttlebutt says that these
> > can be made still faster using caching controllers.
> Mene, mene, tekel, uparshin! This is why the `workstation' market as we've
> known it is doomed -- these machines are getting better faster than the
> Suns and HPs and Irises out there, they run more software, and they're *much*
> cheaper. No one will survive the attack of the killer LOW END micros!
As usual, one must be CAREFUL about what numbers mean and don't mean.
It also helps to read the benchmark code carefully.
1) First, as has been said numerous times here, expandability costs money.
At least some of the other RISC machines are used to run either 100s of
users, programs that use 200MB virtual images, fair numbers of disks, etc.
Tim (properly) includes various disclaimers in the benchmark itself.
2) If something really measures the seek time on one disk, it measures the
seek time on one disk. If there is enough CPU performance to seek the disk
at full speed, it is irrelevant how much faster it is: the benchmark
doesn't get faster. Put another way, on single-threaded kinds of benchmarks,
the only thing that counts is whatever is the bottleneck.
CPU performance is irrelevant for benchmarks that use a few percent of a 386.
3) However, note that the random benchmark doesn't read the same amount of
data on each machine, as it uses BUFSIZ from stdio.h, and that
has different numbers: I'd guess it was 1K on the 386, and 8K on some
of the others. Thus, with 8K, compared to 1K:
a) The disk heads spend 8X longer reading/writing data.
Note that rotational delay can be a noticable chunk of time as
a fraction of the seek time these days.
b) The CPU spends must transfer 8X more data, if it does copies.
c) 8X more space is used in the buffer cache. This means that,
for the same amount of memory, a system with a 1K-block file system
can absorb about 8X more dirtied pages than can one with a 8K, etc.
This means that the knee of the curve moves around a lot, i.e.,
the system with the smaller page size may be able to get away with
NEVER writing one of the blocks dirtied in the random test,
whereas somebody with a bigger one may dirty all of the cache
(since there are 1/8 less blocks in the same space).
NOTE: this is NOT a claim that big blocks are better or worse
than small blocks, merely that there are serious effects
here that can produce meaningless numbers.
4) MORALS:
a) Even trying hard, (and Tim was) it is hard to do
I/O benchmarks without weird quirks. In particular, you are
constantly fighting to outsmart the UNIX buffer cache (or whatever
it uses). There is at least one commercially-used benchmark for
which the dynamic allocation on {Sun, Solbourne, MIPS, and probably
others), causes all kinds of problems [even though it's the right
thing, of course). I've often wanted a syscall that said:
"flush the buffer cache and invalidate everything for benchmarking"
to make life easier, but.... Of course, if there were ever a syscall
that people might be tempted to cripple....
b) One MUST specificy everything that's important about the
configuration. Give me a 1-mips processor, and 100MB of
memory, and I'll beat anybody with 8MB and a zillion-mips on
some of these tests. In addition, it is good to specify
software revs. For instance, RISC/os had a bug for a while
that caused random reads to also issue read-aheads, i.e.,
nearly doubling the number of actual I/Os (argh!) and from
the M/2000 numbers, I suspect that version was used.
(This is fixed now, of course)>
c) You must always look carefully at what a benchmark is
doing before drawing any strong conclusions. Thus, it is
good that Tim posted it so that people could look at the
innards and decide what it meant.
--
-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: m...@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash
DDD: 408-524-7015 or 408-720-1700
USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
Path: gmdzi!unido!mcsun!uunet!lll-winken!sun-barr!newstop!sun!snafu!lm
From: l...@snafu.Sun.COM (Larry McVoy)
Newsgroups: comp.arch
Subject: Re: Unix Filesystem Benchmark Results (long)
Message-ID: <135859@sun.Eng.Sun.COM>
Date: 17 May 90 02:17:24 GMT
References: <1990May13.165810.26723@watdragon.waterloo.edu>
<135710@sun.Eng.Sun.COM> <1990May15.205831.3841@ico.isc.com> <135780@sun.Eng.Sun.COM>
<00936C10.82850A60@KING.ENG.UMD.EDU>
Sender: n...@sun.Eng.Sun.COM
Reply-To: l...@sun.UUCP (Larry McVoy)
Organization: Sun Microsystems, Mountain View
Lines: 18
Posted: Thu May 17 03:17:24 1990
In article <00936C10.82850...@KING.ENG.UMD.EDU> sys...@KING.ENG.UMD.EDU (Doug Mohney)
writes:
>In article <135...@sun.Eng.Sun.COM>, l...@snafu.Sun.COM (Larry McVoy) writes:
>>Check out Wednesday's Wall Street Journal. Apparently we have a $5K
>>sparc box now. My wish list stays the same, the price just dropped by
>>a factor of 2.
>>
>>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
>
>Apparently? You don't know ;-) ("I could tell you, but then I'd have to
>kill you...")
I was playing it safe. I was preannouncing it (by a whole day :-)
---
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 l...@sun.com
Path: gmdzi!unido!mcsun!uunet!crdgw1!zephyrus!davidsen
From: david...@zephyrus.crd.ge.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: Unix Filesystem Benchmark Results (long)
Message-ID: <7717@crdgw1.crd.ge.com>
Date: 17 May 90 13:29:31 GMT
References: <1990May13.165810.26723@watdragon.waterloo.edu>
<135780@sun.Eng.Sun.COM> <1990May16.203856.7384@ico.isc.com>
Sender: n...@crdgw1.crd.ge.com
Reply-To: david...@zephyrus.crd.ge.COM (william E Davidsen)
Organization: .crd.ge.COM
Lines: 31
Posted: Thu May 17 14:29:31 1990
In article <1990May16.203856.7...@ico.isc.com>, r...@ico.isc.com (Dick
Dunn) writes:
|> l...@snafu.Sun.COM (Larry McVoy) writes:
|> > Now, for all those who are saying that Xenix + 386 is the way to go -
|> > STOP!...
|>
|> Oh, stop yourself...who said anything about Xenix? You were following up
|> on an article in which the 386 system was running 386/ix, not Xenix.
|>
|> >...But it's simply not a reasonable comparison - it's what we call apples
|> > to oranges...
|>
|> Which, presumably, is *why* people weren't talking about Xenix.
Xenix is a smaller kernel with (often) lower overhead. SCO UNIX and
ix386 are both (a) larger, (b) slightly slower, and (c) have faster
filesystems. I'm not sure there's a lot to choose, other than small
memory machine running better with Xenix.
|>
|> >...I *need* a window system...
|>
|> So *get* a window system. How about X? And you've got *lots* of displays
|> to choose from, at various tradeoffs in price, speed, and resolution.
I have no idea what the point was here. Obviously you can have X if
you want it, although having virtual terminals is very useful for
applications where you want to see what you're doing. If you need
{FORTRAN, LISP, Ada, BASIC} you can have them, too.
Path: gmdzi!unido!mcsun!uunet!mailrus!cs.utexas.edu!usc!apple!sun-barr!
newstop!sun!snafu!lm
From: l...@snafu.Sun.COM (Larry McVoy)
Newsgroups: comp.arch
Subject: Re: Unix Filesystem Benchmark Results (long)
Message-ID: <135914@sun.Eng.Sun.COM>
Date: 18 May 90 00:07:40 GMT
References: <1990May13.165810.26723@watdragon.waterloo.edu>
<1WQxyF#1PgpgZ6rsnj60x8CW32qY30d=eric@snark.uu.net> <38816@mips.mips.COM>
Sender: n...@sun.Eng.Sun.COM
Reply-To: l...@sun.UUCP (Larry McVoy)
Organization: Sun Microsystems, Mountain View
Lines: 13
Posted: Fri May 18 01:07:40 1990
In article <38...@mips.mips.COM> m...@mips.COM (John Mashey) writes:
> I've often wanted a syscall that said:
> "flush the buffer cache and invalidate everything for benchmarking"
> to make life easier, but.... Of course, if there were ever a syscall
> that people might be tempted to cripple....
This system call exists, it's called unmount(2). That's the safest way to
do what you want - any system that leaves data from that partition in
memory is seriously broken.
---
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 l...@sun.com
Path: gmdzi!unido!mcsun!uunet!samsung!munnari.oz.au!sirius.ucs.adelaide.edu.au!
augean!sibyl!ian
From: i...@sibyl.eleceng.ua.OZ (Ian Dall)
Newsgroups: comp.arch
Subject: Re: 386 machines are workstations?
Message-ID: <634@sibyl.eleceng.ua.OZ>
Date: 18 May 90 01:37:45 GMT
References: <1990May13.165810.26723@watdragon.waterloo.edu> <135780@sun.Eng.Sun.COM>
<1990May16.203856.7384@ico.isc.com> <7717@crdgw1.crd.ge.com>
Reply-To: i...@sibyl.OZ (Ian Dall)
Organization: Engineering, Uni of Adelaide, Australia
Lines: 24
Posted: Fri May 18 02:37:45 1990
In article <7...@crdgw1.crd.ge.com> david...@zephyrus.crd.ge.COM
(william E Davidsen) writes:
}
}In article <1990May16.203856.7...@ico.isc.com>, r...@ico.isc.com (Dick
}Dunn) writes:
}|> l...@snafu.Sun.COM (Larry McVoy) writes:
}
}|> > Now, for all those who are saying that Xenix + 386 is the way to go -
}|> > STOP!...
}|>
}|> Oh, stop yourself...who said anything about Xenix? You were following up
}|> on an article in which the 386 system was running 386/ix, not Xenix.
} Xenix is a smaller kernel with (often) lower overhead. SCO UNIX and
}ix386 are both (a) larger, (b) slightly slower, and (c) have faster
}filesystems.
Zenix, SCO, ix386, who cares. Part of *my* definition of a workstation
is that it doesn't have a 80x86 as a cpu (only 1/2 :-). I was very
disappointed to find that I had recently unwittingly bought an 8086
imbedded in a disk drive. I just hope that whatever it is that infests
the 8086 family isn't contagious to the rest of my hardware!
--
Ian Dall life (n). A sexually transmitted disease which afflicts
some people more severely than others.
Path: gmdzi!unido!mcsun!uunet!aplcen!uakari.primate.wisc.edu!
zaphod.mps.ohio-state.edu!mips!apple!sun-barr!newstop!sun!snafu!lm
From: l...@snafu.Sun.COM (Larry McVoy)
Newsgroups: comp.arch
Subject: Re: 386 machines are workstations?
Message-ID: <135974@sun.Eng.Sun.COM>
Date: 18 May 90 23:35:49 GMT
References: <1990May13.165810.26723@watdragon.waterloo.edu>
<135780@sun.Eng.Sun.COM> <1990May16.203856.7384@ico.isc.com>
<7717@crdgw1.crd.ge.com> <634@sibyl.eleceng.ua.OZ>
Sender: n...@sun.Eng.Sun.COM
Reply-To: l...@sun.UUCP (Larry McVoy)
Organization: Sun Microsystems, Mountain View
Lines: 18
Posted: Sat May 19 00:35:49 1990
In article <6...@sibyl.eleceng.ua.OZ> i...@sibyl.OZ (Ian Dall) writes:
>Zenix, SCO, ix386, who cares. Part of *my* definition of a workstation
>is that it doesn't have a 80x86 as a cpu (only 1/2 :-). I was very
>disappointed to find that I had recently unwittingly bought an 8086
>imbedded in a disk drive. I just hope that whatever it is that infests
>the 8086 family isn't contagious to the rest of my hardware!
This is silly. The 486 is a far cry from a 8086, 80186, 80286, and
even an 80386. When I looked at the data sheet, it looked to me like
it would act like a risc if you fed it risc like intructions - i.e.,
one per clock. And if you needed the long instructions (like divides,
remember them?) it does them in the hardware. We can argue all day
which is better or worse, but IMHO the 486 is a reasonable chip.
Needs work, but I can say the same about Sparc, Mips, and 88K.
---
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 l...@sun.com
Path: gmdzi!unido!mcsun!uunet!clyde.concordia.ca!news-server.csri.toronto.edu!
utgpu!utzoo!henry
From: he...@utzoo.uucp (Henry Spencer)
Newsgroups: comp.arch
Subject: Re: 386 machines are workstations?
Message-ID: <1990May19.224844.15669@utzoo.uucp>
Date: 19 May 90 22:48:44 GMT
References: <1990May13.165810.26723@watdragon.waterloo.edu>
<135780@sun.Eng.Sun.COM> <1990May16.203856.7384@ico.isc.com>
<7717@crdgw1.crd.ge.com> <634@sibyl.eleceng.ua.OZ> <135974@sun.Eng.Sun.COM>
Organization: U of Toronto Zoology
Lines: 12
Posted: Sat May 19 23:48:44 1990
In article <135...@sun.Eng.Sun.COM> l...@sun.UUCP (Larry McVoy) writes:
>This is silly. The 486 is a far cry from a 8086, 80186, 80286, and
>even an 80386...
Did they finally give it a reasonable number of registers? That was
about the only thing that was terribly wrong with the 386, apart from
unimpressive performance compared to RISCs (a problem the 486 shares --
the 860, built at the same time with similar tools, blows the doors off
the 486).
--
Life is too short to spend | Henry Spencer at U of Toronto Zoology
debugging Intel parts. -Van J.| uunet!attcan!utzoo!henry he...@zoo.toronto.edu
Path: gmdzi!unido!mcsun!uunet!aplcen!samsung!zaphod.mps.ohio-state.edu!
mips!winchester!mash
From: m...@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: 386 machines are workstations?
Message-ID: <38928@mips.mips.COM>
Date: 21 May 90 03:32:58 GMT
References: <1990May13.165810.26723@watdragon.waterloo.edu>
<135780@sun.Eng.Sun.COM> <1990May16.203856.7384@ico.isc.com>
<7717@crdgw1.crd.ge.com> <634@sibyl.eleceng.ua.OZ> <135974@sun.Eng.Sun.COM>
Sender: n...@mips.COM
Reply-To: m...@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Inc.
Lines: 29
Posted: Mon May 21 04:32:58 1990
In article <135...@sun.Eng.Sun.COM> l...@sun.UUCP (Larry McVoy) writes:
>This is silly. The 486 is a far cry from a 8086, 80186, 80286, and
>even an 80386. When I looked at the data sheet, it looked to me like
>it would act like a risc if you fed it risc like intructions - i.e.,...
Yes. It will be good to get SPEC numbers and other benchmarks on more
machines. From the ones I've seen, I observe that a 486 with big cache
gives some RISCs competition at same clock rate + cache size,
at least on integer performance (but not usually floating point),
and cost is harder to get at. (I.e., an R3000 with similar memory
system and clcok looks like about 1.5X on integer, and 2-2.5X on FP,
although the FP varies, as usual. On the SPEC set, at least one of the
benchmarks (tomcatv) is absolutely brutal on machines with few
registers; actually, it's even nasty to machines with "only"
32 integer and 16 64-bit floating registers :-)
Certainly the 486 is a pretty good implementation of the archticture,
and implementation counts.
A really interesting comparison will be to look at the landscape
when all of the multiple-issue machines are public, i.e.,
the i486 has architecturally, in some sense, followed in some fo the
same paths as have mainframes/superminis in getting single-cycle
issue rates for the most common/simple instructions.
Thus, the next round will be interesting to see.
--
-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: m...@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash
DDD: 408-524-7015 or 408-720-1700
USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
Path: gmdzi!unido!mcsun!uunet!snorkelwacker!tut.cis.ohio-state.edu!
zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!ut-emx!hcobb
From: hc...@walt.cc.utexas.edu (Henry J. Cobb)
Newsgroups: comp.arch
Subject: 68000 and Workstations.
Message-ID: <30273@ut-emx.UUCP>
Date: 22 May 90 02:08:29 GMT
References: <1990May20.170544.23997@xavax.com> <21448@megaron.cs.arizona.edu>
Sender: n...@ut-emx.UUCP
Organization: The University of Texas at Austin
Lines: 11
Posted: Tue May 22 03:08:29 1990
In-reply-to: druschel@cs.arizona.edu (Peter Druschel)
The 68000 did mantain a form of hardware compatibility in the E-clock,
allowing the continued use of cheap I/O chips.
Personally I side with Dave Haynie: A Workstation is defined by use,
not features. If most are bought for individual use and the software is
purchased rather than leased, then it is a Personal Computer, not a
Workstation.
Henry J. Cobb hc...@ccwf.cc.utexas.edu
Tyrant of the SFB-tactics E-Mailing list.
Path: gmdzi!unido!mcsun!uunet!voa3!ck
From: c...@voa3.UUCP (Chris Kern)
Newsgroups: comp.arch
Subject: Macintosh OS (was: 68000 and Workstations.)
Message-ID: <37@voa3.UUCP>
Date: 25 May 90 16:43:14 GMT
References: <30273@ut-emx.UUCP> <76700207@p.cs.uiuc.edu>
<1990May24.114553.10301@phri.nyu.edu> <BZS.90May24174257@world.std.com>
Reply-To: c...@voa3.UUCP (Chris Kern)
Organization: Voice of America, Washington, D.C.
Lines: 8
Posted: Fri May 25 17:43:14 1990
For those of use who don't have any experience with the Mac OS, could
someone explain what its deficiencies are with respect to multitasking?
Is it that the OS doesn't do time-slicing? Does a context switch have
to wait for some event at the application level? How is multitasking
implemented?
--
Chris Kern Voice of America, Washington, D.C.
...uunet!voa3!ck +1 202-619-2020
Path: gmdzi!unido!mcsun!uunet!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!
rpi!uwm.edu!srcsip!jhereg!wd0gol!newave!john
From: j...@newave.UUCP (John A. Weeks III)
Newsgroups: comp.arch
Subject: Re: Macintosh OS (was: 68000 and Workstations.)
Summary: Is it really an OS?
Message-ID: <402@newave.UUCP>
Date: 25 May 90 21:45:34 GMT
References: <30273@ut-emx.UUCP> <76700207@p.cs.uiuc.edu>
<1990May24.114553.10301@phri.nyu.edu> <BZS.90May24174257@world.std.com>
<37@voa3.UUCP>
Reply-To: j...@newave.mn.org (John A. Weeks III)
Organization: NeWave Communications Ltd, Eden Prairie, MN
Lines: 25
Posted: Fri May 25 22:45:34 1990
In article <3...@voa3.UUCP> c...@voa3.UUCP (Chris Kern) writes:
>For those of use who don't have any experience with the Mac OS, could
>someone explain what its deficiencies are with respect to multitasking?
Can the Macintosh System be called an "Operating System"? Ignoring
system 7.0, the Mac is a collection of procedures, some of which are
in ROM, that everyone agrees to call in the right order. If anyone
screws up, you get a bomb. There is no real multi-tasking, no scheduler,
no device or file locking, memory protection, processes, forking, etc.
What many people refer to as the O/S is really the finder program. And
yes, it is an application just like any other, and you are not required
to use it. In fact, Apple has a thing called "mini-finder" that allows
you to start Mac programs without running finder.
I am not saying that this is good or bad, but does this qualify as an O/S.
How about MS-DOS?
-john-
--
===============================================================================
John A. Weeks III (612) 942-6969 j...@newave.mn.org
NeWave Communications ...uunet!rosevax!bungia!wd0gol!newave!john
===============================================================================
Path: gmdzi!unido!mcsun!uunet!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!
ux1.cso.uiuc.edu!m.cs.uiuc.edu!gillies
From: gill...@m.cs.uiuc.edu
Newsgroups: comp.arch
Subject: Re: Macintosh OS (was: 68000 and Wo
Message-ID: <3300131@m.cs.uiuc.edu>
Date: 26 May 90 17:58:00 GMT
References: <402@newave.UUCP>
Lines: 41
Nf-ID: #R:newave.UUCP:402:m.cs.uiuc.edu:3300131:000:2108
Nf-From: m.cs.uiuc.edu!gillies May 26 12:58:00 1990
Posted: Sat May 26 18:58:00 1990
> Can the Macintosh System be called an "Operating System"? Ignoring
> system 7.0, the Mac is a collection of procedures, some of which are
> in ROM, that everyone agrees to call in the right order. If anyone
> screws up, you get a bomb. There is no real multi-tasking, no scheduler,
> no device or file locking, memory protection, processes, forking, etc.
>
> What many people refer to as the O/S is really the finder program.
The finder is a shell, not the operating system. There is a very
beautiful paper by Butler Lampson, I believe, called "An open
Operating System for a Single-User Machine" (circa 82-84). Basically,
Lampson observes that the advent of the personal computer allows us to
return to the golden days of the 1950's, with a single programmer, a
library, and a dedicated machine. Apple's OS is a very close
approximation of lampson's ideal environment.
Some of the things that are important in a single-user operating
system are:
1. fast reboot ( < 10 secs)
2. no protected kernel, to allow easy modification of software
3. single address space, to maximize modifiability of software
4. automatic scavenger, to repair file system in case of harmful crash
(limited scavenging available on macintosh)
5. file system (mac file system has write-protect locking, by the way)
6. drivers (mac has half a dozen device drivers)
7. overlay loader (because early macs (& Alto) had no VM)
8. well-developed screen management package (window system,
vertical retrace synchronization), including picture language.
9. Ubiquitous protocol for serializing data on disk (in resources)
(xerox CPUs use the courier data encoding format)
By these standards the macintosh system qualifies handsomely as an
operating system. In fact, until NeWS was written, sun didn't even
have [8], and I wonder if it has [9]? Maybe SunView does not qualify
as a single-user operating system. 8-)
Don Gillies, Dept. of Computer Science, University of Illinois
1304 W. Springfield, Urbana, Ill 61801
ARPA: gill...@cs.uiuc.edu UUCP: {uunet,harvard}!uiucdcs!gillies
Path: gmdzi!unido!mcsun!uunet!tut.cis.ohio-state.edu!pt.cs.cmu.edu!
MATHOM.GANDALF.CS.CMU.EDU!lindsay
From: lind...@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: Personal OS
Message-ID: <9437@pt.cs.cmu.edu>
Date: 27 May 90 03:34:46 GMT
References: <402@newave.UUCP> <3300131@m.cs.uiuc.edu>
Organization: Carnegie-Mellon University, CS/RI
Lines: 38
Posted: Sun May 27 04:34:46 1990
In article <3300...@m.cs.uiuc.edu> gill...@m.cs.uiuc.edu writes:
>There is a very
>beautiful paper by Butler Lampson, I believe, called "An open
>Operating System for a Single-User Machine" (circa 82-84). Basically,
>Lampson observes that the advent of the personal computer allows us to
>return to the golden days of the 1950's, with a single programmer, a
>library, and a dedicated machine. Apple's OS is a very close
>approximation of lampson's ideal environment.
>Some of the things that are important in a single-user operating
>system are:
> 2. no protected kernel, to allow easy modification of software
> 3. single address space, to maximize modifiability of software
I realize that Butler convinced some PARC people of the correctness
of this view. I have a great deal of respect for these people: but
on this point, I consider them to be naive and deluded. Not everyone
out there is a PARC-quality researcher, and not every user out there
will run only sanctified applications. The hardware cost argument
has gone away, and any speed argument has gone away. Plus, that
famous "bloat" leaves me with 65 processes on my workstation as I
type. Don't ask me what they all do. Do I trust that they are all
debugged? Hah! I KNOW that some of them aren't, and I don't trust
the rest. Nor do I want the nightmare of making "easy modifications"
to these intricate, hard-to-test things. Is this "golden age" going
to simplify them, going to reduce this bloat? Would you like to buy
this bridge I own in Brooklyn?
In summary: if my workstation had a single address space, I'd sell it
and buy something adequate. (Sorry, Ed.)
> 7. overlay loader (because early macs (& Alto) had no VM)
I'm old enough to remember when overlays were the way you built
applications on minicomputers. They were a god-awful source of bugs
and grief, and a horrendous waste of effort. In summary: bletch.
--
Don D.C.Lindsay Carnegie Mellon Computer Science
Path: gmdzi!unido!mcsun!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!
think!barmar
From: bar...@think.com (Barry Margolin)
Newsgroups: comp.arch
Subject: Re: Personal OS
Message-ID: <36849@think.Think.COM>
Date: 27 May 90 04:53:24 GMT
References: <402@newave.UUCP> <3300131@m.cs.uiuc.edu> <9437@pt.cs.cmu.edu>
Sender: n...@Think.COM
Reply-To: bar...@nugodot.think.com (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 36
Posted: Sun May 27 05:53:24 1990
In article <9...@pt.cs.cmu.edu> lind...@MATHOM.GANDALF.CS.CMU.EDU
(Donald Lindsay) writes:
>In summary: if my workstation had a single address space, I'd sell it
>and buy something adequate. (Sorry, Ed.)
Actually, one of the best reasons for a single address space is to simplify
sharing of data between applications, which promotes integrated software.
MIT-descended Lisp Machines are a good example of this. The debugger can
display source code from the editor, the editor has access to the compiler
warning database, etc. It's true that integrated software can be written
when the applications have walls between them, but it's harder and rarely
very extensible. A protocol has to be provided, and you are usually
restricted to the forms of communication that are preconceived by the
designers; if all the applications are designed together this may be good
enough, but if they have differing heritages you may be out of luck.
Many Macintosh utilities take advantage of the single address space. For
example, there's an auto-save utility, which periodically causes the
application to invoke its "Save" menu item; it has to look around in the
application's address space to find the identity of the menu entry.
>> 7. overlay loader (because early macs (& Alto) had no VM)
>I'm old enough to remember when overlays were the way you built
>applications on minicomputers. They were a god-awful source of bugs
>and grief, and a horrendous waste of effort. In summary: bletch.
Remember, the article was written in the early 80's, when VM on personal
computers was almost unthinkable (indeed, hard disks on personal computers
were considered a luxury -- I think the Winchester disk is probably one of
the most important computer technologies of the 80's). If overlays are
automated, as is done on the Mac, then bugs are reduced. It's a reasonable
compromise, but it's certainly not as nice as VM with demand paging.
--
Barry Margolin, Thinking Machines Corp.
bar...@think.com
{uunet,harvard}!think!barmar
Path: gmdzi!unido!mcsun!uunet!clyde.concordia.ca!news-server.csri.toronto.edu!
utgpu!utzoo!henry
From: he...@utzoo.uucp (Henry Spencer)
Newsgroups: comp.arch
Subject: Re: Personal OS
Message-ID: <1990May28.155933.20953@utzoo.uucp>
Date: 28 May 90 15:59:33 GMT
References: <402@newave.UUCP> <3300131@m.cs.uiuc.edu> <9437@pt.cs.cmu.edu>
<36849@think.Think.COM>
Organization: U of Toronto Zoology
Lines: 34
Posted: Mon May 28 16:59:33 1990
In article <36...@think.Think.COM> bar...@nugodot.think.com (Barry Margolin)
writes:
>>In summary: if my workstation had a single address space, I'd sell it
>>and buy something adequate. (Sorry, Ed.)
>
>Actually, one of the best reasons for a single address space is to simplify
>sharing of data between applications, which promotes integrated software...
>... It's true that integrated software can be written
>when the applications have walls between them, but it's harder and rarely
>very extensible...
There is no problem in writing integrated software on a multi-space machine,
you just do it all in one space and pretend that the walls don't exist. On
the other hand, a one-space machine with flimsy protection makes it very
difficult to write multiple programs that are guaranteed *not* to interfere
with each other.
If you look at the software on the Alto, the system from which much of the
one-space mythology is descended, you find that there is no notion of
non-interfering parallel processes at all -- all parallelism has to be
preplanned -- and the only interprocess-communication method that works
between independently-written programs is the file system.
The very "wide" interface made possible by sharing all memory is a
two-edged sword. It is very powerful for programs that want to cooperate
and are willing to work at it. But it makes it very difficult for programs
to work together without such advance planning, precisely *because* the
inter-program interface is so versatile and powerful and demands that so
many choices be made. The Unix approach, with independent programs plugged
together by a simple command interpreter, simply does not exist on many
such systems. The interfaces are too rich and too powerful for random
programs to talk to each other easily.
--
As a user I'll take speed over| Henry Spencer at U of Toronto Zoology
features any day. -A.Tanenbaum| uunet!attcan!utzoo!henry he...@zoo.toronto.edu
Path: gmdzi!unido!mcsun!uunet!samsung!munnari.oz.au!sirius.ucs.adelaide.edu.au!
augean!sibyl!ian
From: i...@sibyl.eleceng.ua.OZ (Ian Dall)
Newsgroups: comp.arch
Subject: Re: Personal OS
Message-ID: <643@sibyl.eleceng.ua.OZ>
Date: 28 May 90 03:47:20 GMT
References: <402@newave.UUCP> <3300131@m.cs.uiuc.edu> <9437@pt.cs.cmu.edu>
<36849@think.Think.COM>
Reply-To: i...@sibyl.OZ (Ian Dall)
Organization: Engineering, Uni of Adelaide, Australia
Lines: 42
Posted: Mon May 28 04:47:20 1990
In article <36...@think.Think.COM> bar...@nugodot.think.com (Barry Margolin)
writes:
>
>Actually, one of the best reasons for a single address space is to simplify
>sharing of data between applications, which promotes integrated software.
"Forces", I would have said.
>warning database, etc. It's true that integrated software can be written
>when the applications have walls between them, but it's harder and rarely
>very extensible. A protocol has to be provided, and you are usually
>restricted to the forms of communication that are preconceived by the
>designers; if all the applications are designed together this may be good
>enough, but if they have differing heritages you may be out of luck.
If you are using a shared address space as your means of IPC you are
even more out of luck if the applications are not designed together.
There are many "proofs of existance" to show that a single shared
address space for OS and processes can work. That is not to say that
it is a desirable environment. Many people (myself included) use a
multiuser operating system predominantly with only one active user. I
cannot count the number of times I have had a process die with a
SIGSEGV. Count each of those as a probable system crash. No thanks! I
have 34 processes running on this machine at the moment and I am the
only user. Some of those (esp emacs), have some state dependent on
what I am currently doing. It would be a major inconcenience to loose
that state every time I try and debug a program.
Even running "debugged" official applications ("MacWrite" etc), I have
seen Macs get into a state where they have to be reset. Ditto with
MSDOS machines. The rapid reboot which was quoted as being necessary
in a single user operating system is due to the frequency of the crashes
in such a system.
Of course, processes get into "stuck" states on a multi-tasking OS as
well. The difference is that you can normally recover with only the
death of that one process.
--
Ian Dall life (n). A sexually transmitted disease which afflicts
some people more severely than others.
Path: gmdzi!unido!mcsun!uunet!samsung!think!barmar
From: bar...@think.com (Barry Margolin)
Newsgroups: comp.arch
Subject: Re: Personal OS
Message-ID: <36861@think.Think.COM>
Date: 29 May 90 01:38:16 GMT
References: <402@newave.UUCP> <3300131@m.cs.uiuc.edu> <9437@pt.cs.cmu.edu>
<36849@think.Think.COM> <643@sibyl.eleceng.ua.OZ>
Sender: n...@Think.COM
Reply-To: bar...@nugodot.think.com (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 34
Posted: Tue May 29 02:38:16 1990
In article <6...@sibyl.eleceng.ua.OZ> i...@sibyl.OZ (Ian Dall) writes:
>There are many "proofs of existance" to show that a single shared
>address space for OS and processes can work. That is not to say that
>it is a desirable environment. Many people (myself included) use a
>multiuser operating system predominantly with only one active user. I
>cannot count the number of times I have had a process die with a
>SIGSEGV. Count each of those as a probable system crash. No thanks!
OK, maybe I should qualify my point and say that a single address space is
reasonable when there's a decent language/runtime system. Almost all the
system failures we get on Symbolics Lisp Machine are due to hardware
problems. The hardware, Lisp language and runtime system make it difficult
to scribble randomly on memory. Sure, if a program were to manipulate the
scheduler's data structures directly and make a mistake it could bring the
system to its knees, but it's inlikely to happen to a program that isn't
*trying* to manipulate the OS, and patching the OS is likely to crash any
system. When ordinary application programs do get errors (and Lisp
Machines do lots more error checking, such as number and types of
arguments, than most other systems) they just invoke the debugger, abort,
or invoke programmed condition handlers.
So, I would say that the problem with the Mac is not that it has a single
address space, but that its typical language and runtime systems don't
provide adequate for this mode. Address space protection on multiuser
systems exists for security; programmers are still responsible for writing
programs that follow the rules, e.g. only address memory you have
allocated, pass appropriate arguments when calling library routines or
system calls, etc.
--
Barry Margolin, Thinking Machines Corp.
bar...@think.com
{uunet,harvard}!think!barmar
Path: gmdzi!unido!mcsun!sunic!uupsi!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!
elroy.jpl.nasa.gov!ames!amdahl!key!sjc
From: s...@key.COM (Steve Correll)
Newsgroups: comp.arch
Subject: Re: Macintosh OS
Message-ID: <1935@key.COM>
Date: 30 May 90 15:23:17 GMT
References: <30273@ut-emx.UUCP> <76700207@p.cs.uiuc.edu> <402@newave.UUCP>
Organization: Key Computer Labs, Fremont, CA
Lines: 18
Posted: Wed May 30 16:23:17 1990
In article <4...@newave.UUCP>, j...@newave.UUCP (John A. Weeks III) writes:
> Can the Macintosh System be called an "Operating System"? Ignoring
> system 7.0, the Mac is a collection of procedures, some of which are
> in ROM, that everyone agrees to call in the right order. If anyone
> screws up, you get a bomb. There is no real multi-tasking, no scheduler,
> no device or file locking, memory protection, processes, forking, etc.
Suppose you implemented the C library standalone on a bare machine, adding the
capability to execute multiple C programs by switching from one to another
during calls to the library. Would that be an operating system? People
accustomed to conventional timesharing systems might answer "no", but people
accustomed to simple ROM-able operating systems might answer "yes".
The Mac OS is a deluxe, highly graphical version of that approach. Myself, I
think Apple's advertising slogan ought to be "The User Interface _is_ the
Computer".
--
...{sun,pyramid}!pacbell!key!sjc Steve Correll
Path: gmdzi!unido!mcsun!uunet!cs.utexas.edu!samsung!rex!ames!eos!shelby!
neon!Kermit.Stanford.EDU!philip
From: phi...@Kermit.Stanford.EDU (Philip Machanick)
Newsgroups: comp.arch
Subject: Re: Macintosh OS
Message-ID: <1990May30.230248.6200@Neon.Stanford.EDU>
Date: 30 May 90 23:02:48 GMT
References: <1935@key.COM> <30273@ut-emx.UUCP> <76700207@p.cs.uiuc.edu>
<402@newave.UUCP>
Sender: n...@Neon.Stanford.EDU (USENET News System)
Reply-To: phi...@pescadero.stanford.edu
Organization: Computer Science Department, Stanford University
Lines: 24
Posted: Thu May 31 00:02:48 1990
In article <1...@key.COM>, s...@key.COM (Steve Correll) writes:
> In article <4...@newave.UUCP>, j...@newave.UUCP (John A. Weeks III) writes:
> > Can the Macintosh System be called an "Operating System"? Ignoring
> > system 7.0, the Mac is a collection of procedures, some of which are
> > in ROM, that everyone agrees to call in the right order. If anyone
> > screws up, you get a bomb. There is no real multi-tasking, no scheduler,
> > no device or file locking, memory protection, processes, forking, etc.
>
> Suppose you implemented the C library standalone on a bare machine,
adding the
> capability to execute multiple C programs by switching from one to another
> during calls to the library. Would that be an operating system? People
> accustomed to conventional timesharing systems might answer "no", but people
> accustomed to simple ROM-able operating systems might answer "yes".
This "is the Mac OS an OS" line seems to assume that an OS _only_ defines
multitasking. I always thought it defined a whole bunch of abstractions, like
the file system. The Mac does most of this conventional stuff, plus a sort
of abstract machine model for graphics. Maybe the implementation is not great
because you can break the abstractions too easily, but that's a different
issue.
Philip Machanick
phi...@pescadero.stanford.edu
Path: gmdzi!unido!mcsun!uunet!aplcen!samsung!usc!snorkelwacker!apple!oracle!news
From: csimm...@jewel.oracle.com (Charles Simmons)
Newsgroups: comp.arch
Subject: Re: Macintosh OS
Message-ID: <1990Jun2.132847.14292@oracle.com>
Date: 2 Jun 90 13:28:47 GMT
References: <1990May30.230248.6200@Neon.Stanford.EDU> <1935@key.COM>
<30273@ut-emx.UUCP> <76700207@p.cs.uiuc.edu> <402@newave.UUCP>
Sender: n...@oracle.com
Reply-To: csimm...@oracle.com
Organization: Oracle Corp
Lines: 42
Posted: Sat Jun 2 14:28:47 1990
In article <1990May30.230248.6...@Neon.Stanford.EDU>,
phi...@Kermit.Stanford.EDU (Philip Machanick) writes:
> From: phi...@Kermit.Stanford.EDU (Philip Machanick)
> Subject: Re: Macintosh OS
> Date: 30 May 90 23:02:48 GMT
>
> In article <1...@key.COM>, s...@key.COM (Steve Correll) writes:
> > In article <4...@newave.UUCP>, j...@newave.UUCP (John A. Weeks III) writes:
> > > Can the Macintosh System be called an "Operating System"? Ignoring
> > > system 7.0, the Mac is a collection of procedures, some of which are
> > > in ROM, that everyone agrees to call in the right order. If anyone
> > > screws up, you get a bomb. There is no real multi-tasking, no scheduler,
> > > no device or file locking, memory protection, processes, forking, etc.
> >
> > Suppose you implemented the C library standalone on a bare machine,
> adding the
> > capability to execute multiple C programs by switching from one to another
> > during calls to the library. Would that be an operating system? People
> > accustomed to conventional timesharing systems might answer "no",
but people
> > accustomed to simple ROM-able operating systems might answer "yes".
>
> This "is the Mac OS an OS" line seems to assume that an OS _only_ defines
> multitasking. I always thought it defined a whole bunch of abstractions, like
> the file system. The Mac does most of this conventional stuff, plus a sort
> of abstract machine model for graphics. Maybe the implementation is not great
> because you can break the abstractions too easily, but that's a different
> issue.
>
> Philip Machanick
> phi...@pescadero.stanford.edu
This "is the Mac OS an OS" line seems to assume that an OS defines a
gruntload of really strange abstractions: like what your graphical user
interface should look like. I always thought an OS should define a very
minimal number of abstractions: like how the cpu resource is allocated
to different processes (scheduling); like how the memory resource is
allocated to different processes; and like how inter-process communications
is performed. File systems? Relational databases? TCP/IP? Let them
be done by user-level processes.
-- Chuck
Path: gmdzi!unido!mcsun!uunet!ficc!peter
From: pe...@ficc.ferranti.com (Peter da Silva)
Newsgroups: comp.arch
Subject: Re: Macintosh OS
Message-ID: <Y5X3=SB@xds13.ferranti.com>
Date: 4 Jun 90 16:13:16 GMT
References: <1990May30.230248.6200@Neon.Stanford.EDU> <1935@key.COM>
<30273@ut-emx.UUCP> <76700207@p.cs.uiuc.edu> <402@newave.UUCP>
<1990Jun2.132847.14292@oracle.com>
Reply-To: pe...@ficc.ferranti.com (Peter da Silva)
Organization: Xenix Support, FICC
Lines: 11
Posted: Mon Jun 4 17:13:16 1990
In article <1990Jun2.132847.14...@oracle.com> csimm...@oracle.com writes:
> This "is the Mac OS an OS" line seems to assume that an OS defines a
> gruntload of really strange abstractions: like what your graphical user
> interface should look like. I always thought an OS should define a very
> minimal number of abstractions: like how the cpu resource is allocated
> to different processes (scheduling)...
Exactly. An operating system is basically a resource manager for programs.
And one of the most important resources avalable is CPU time. An operating
system that does not manage that resource is so primitive as to barely
qualify for the name.
--
`-_-' Peter da Silva. +1 713 274 5180. <pe...@ficc.ferranti.com>
'U` Have you hugged your wolf today? <pe...@sugar.hackercorp.com>
@FIN Dirty words: Zhghnyyl erphefvir vayvar shapgvbaf.
Path: gmdzi!unido!mcsun!uunet!tut.cis.ohio-state.edu!cs.utexas.edu!ntvaxb!ac08
From: a...@vaxb.acs.unt.edu
Newsgroups: comp.arch
Subject: Re: Macintosh OS
Message-ID: <26437.266ae612@vaxb.acs.unt.edu>
Date: 4 Jun 90 22:52:02 GMT
References: <1990May30.230248.6200@Neon.Stanford.EDU> <1935@key.COM>
<30273@ut-emx.UUCP> <76700207@p.cs.uiuc.edu> <402@newave.UUCP>
<1990Jun2.132847.14292@oracle.com> <Y5X3=SB@xds13.ferranti.com>
Lines: 28
Posted: Mon Jun 4 23:52:02 1990
In article <Y5X3...@xds13.ferranti.com>, pe...@ficc.ferranti.com (Peter da Silva)
writes:
> In article <1990Jun2.132847.14...@oracle.com> csimm...@oracle.com writes:
>> This "is the Mac OS an OS" line seems to assume that an OS defines a
>> gruntload of really strange abstractions: like what your graphical user
>> interface should look like. I always thought an OS should define a very
>> minimal number of abstractions: like how the cpu resource is allocated
>> to different processes (scheduling)...
>
> Exactly. An operating system is basically a resource manager for programs.
> And one of the most important resources avalable is CPU time. An operating
> system that does not manage that resource is so primitive as to barely
> qualify for the name.
> --
> Peter da Silva
Oh, yeah, real important. For most small (single-user) machines, the CPU is
really "working" at about 1% of capacity... and the few times it's up
to that capacity, it's usually doing something to interface with a user...
Sorry- come up with a better argument.... you were doing better with the
"memory management" thing. People run out of memory a lot more than they
"peg the needle" with the CPU... And those preemptive multitasking systems
suck RAM like nobody's business...
C Irby
a...@vaxb.acs.unt.edu
ac08@untvax
Path: gmdzi!unido!mcsun!uunet!ficc!peter
From: pe...@ficc.ferranti.com (Peter da Silva)
Newsgroups: comp.arch
Subject: Re: Macintosh OS
Message-ID: <M0Y3WUE@xds13.ferranti.com>
Date: 5 Jun 90 17:55:37 GMT
References: <1990May30.230248.6200@Neon.Stanford.EDU> <1935@key.COM>
<30273@ut-emx.UUCP> <76700207@p.cs.uiuc.edu> <402@newave.UUCP>
<1990Jun2.132847.14292@oracle.com> <Y5X3=SB@xds13.ferranti.com>
<26437.266ae612@vaxb.acs.unt.edu>
Reply-To: pe...@ficc.ferranti.com (Peter da Silva)
Organization: Xenix Support, FICC
Lines: 32
Posted: Tue Jun 5 18:55:37 1990
I said: an O/S is basically a resource manager, and CPU time is one of the
most important resources.
In article <26437.266ae...@vaxb.acs.unt.edu> a...@vaxb.acs.unt.edu writes:
> Oh, yeah, real important. For most small (single-user) machines, the CPU is
> really "working" at about 1% of capacity... and the few times it's up
> to that capacity, it's usually doing something to interface with a user...
The fact that you have a lot of CPU time to manage, or a little, is pretty
much irrelevant. The point is that it's got to be allocated. On the Mac this
is done by hand, by each and every application program. Some programs are
specially written to do a better job of this... these are called Desk
Accessories. they have to stay in memory all the time, or you don't have
them available. That's why, on the Mac...
> People run out of memory a lot more than they
> "peg the needle" with the CPU...
... and on the IBM-PC, too. Because to have a program available at short
notice it has to be pretty much loaded at boot time. Or you have to load
a kludgey context switcher that requires you pre-allocate memory. The reason
the Mac chews memory is that it doesn't have...
> And those preemptive multitasking systems
> suck RAM like nobody's business...
Nope. They free it, by making all your tools available at any time, whether
the guy who wrote the application you're using was a good programmer or a
mediocre one. I still have a 512K Amiga 1000, and it's still got more
horsepower left over for *me* than your multimeg Mac-II-whatever.
Remember... time is not conserved. Memory is.
--
`-_-' Peter da Silva. +1 713 274 5180. <pe...@ficc.ferranti.com>
'U` Have you hugged your wolf today? <pe...@sugar.hackercorp.com>
@FIN Dirty words: Zhghnyyl erphefvir vayvar shapgvbaf.
Path: gmdzi!unido!mcsun!uunet!decwrl!apple!uokmax!d.cs.okstate.edu!minich
From: min...@d.cs.okstate.edu (Robert Minich)
Newsgroups: comp.arch
Subject: Re: Macintosh OS
Message-ID: <1990Jun6.055847.14995@d.cs.okstate.edu>
Date: 6 Jun 90 05:58:47 GMT
References: <M0Y3WUE@xds13.ferranti.com>
Organization: Oklahoma State University
Lines: 54
Posted: Wed Jun 6 06:58:47 1990
pe...@ficc.ferranti.com (Peter da Silva):
| The fact that you have a lot of CPU time to manage, or a little, is pretty
| much irrelevant. The point is that it's got to be allocated. On the Mac this
| is done by hand, by each and every application program. Some programs are
| specially written to do a better job of this... these are called Desk
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| Accessories. they have to stay in memory all the time, or you don't have
^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| them available. That's why, on the Mac...
^^^^^^^^^^^^^^^
|
|> People run out of memory a lot more than they
|> "peg the needle" with the CPU...
|
| ... and on the IBM-PC, too. Because to have a program available at short
| notice it has to be pretty much loaded at boot time. Or you have to load
| a kludgey context switcher that requires you pre-allocate memory. The reason
| the Mac chews memory is that it doesn't have...
|
|> And those preemptive multitasking systems
|> suck RAM like nobody's business...
|
| Nope. They free it, by making all your tools available at any time, whether
| the guy who wrote the application you're using was a good programmer or a
| mediocre one. I still have a 512K Amiga 1000, and it's still got more
| horsepower left over for *me* than your multimeg Mac-II-whatever.
Bzzzt. Lets clear up a couple misconceptions, here. First, the is no
requirement that desk accessories be any more graceful about yielding
CPU than any application. Second, DA's are not loaded at boot time as
implied above. They are loaded on demand.
Something that is even more relevant to this whole discussion is that
not all programs get CPU while they are in the background. There is
twiddleable bit that determines this. This bit was added with the
release of MultiFinder. Setting it implies that the program was written
to actually do something in the background, acknowledging the
limitations of MultiFinder and taking the responsibility to yield CPU
time frequently enough that the foreground application does not become
sluggish. If this bit isn't set, the program will never get any time in
background (exception: unless it has to update the contents of a
window).
So the whole point is that any background app that hogs the CPU was
written irresponsibly, even though it may come from Apple. (MacWrite and
MacPaint both did naughty things!)
Let me say again that preemptive multitasking is not a necessity for
99% of the Mac community. I won't mind when the Mac does do preemption,
though. I have yet to see any reason other than poor programming that
cooperative multitasking may be unacceptable for most people.
--
| _ /| | Robert Minich |
| \'o.O' | Oklahoma State University |
| =(___)= | min...@d.cs.okstate.edu |
| U | - Bill sez "Ackphtth" |
Path: gmdzi!unido!mcsun!sunic!nuug!hod!rpi!zaphod.mps.ohio-state.edu!
usc!apple!sun-barr!newstop!texsun!texbell!ficc!peter
From: pe...@ficc.ferranti.com (Peter da Silva)
Newsgroups: comp.arch
Subject: Re: Macintosh OS
Message-ID: <:SY35CD@xds13.ferranti.com>
Date: 6 Jun 90 13:48:58 GMT
References: <M0Y3WUE@xds13.ferranti.com> <1990Jun6.055847.14995@d.cs.okstate.edu>
Reply-To: pe...@ficc.ferranti.com (Peter da Silva)
Organization: Xenix Support, FICC
Lines: 11
Posted: Wed Jun 6 14:48:58 1990
In article <1990Jun6.055847.14...@d.cs.okstate.edu> min...@d.cs.okstate.edu
(Robert Minich) writes:
> Let me say again that preemptive multitasking is not a necessity for
> 99% of the Mac community. I won't mind when the Mac does do preemption,
> though. I have yet to see any reason other than poor programming that
> cooperative multitasking may be unacceptable for most people.
How about the fact that programmers may have better things to do with their
time than warp code to fit into the windowing universe? I realise that on
the mac 90% of the programs are 90% user-interface, but that's not always
the best way to do things. A compiler, for example, really has no business
calling GetNextEvent *ever*.
--
`-_-' Peter da Silva. +1 713 274 5180. <pe...@ficc.ferranti.com>
'U` Have you hugged your wolf today? <pe...@sugar.hackercorp.com>
@FIN Dirty words: Zhghnyyl erphefvir vayvar shapgvbaf.
Path: gmdzi!unido!mcsun!uunet!aplcen!samsung!cs.utexas.edu!mailrus!ncar!
midway!news
From: gft_rob...@gsbacd.uchicago.edu
Newsgroups: comp.arch
Subject: Re: Macintosh OS
Message-ID: <1990Jun6.222126.2888@midway.uchicago.edu>
Date: 6 Jun 90 23:20:40 GMT
Sender: n...@midway.uchicago.edu (News Administrator)
Organization: University of Chicago Graduate School of Business
Lines: 29
Posted: Thu Jun 7 00:20:40 1990
-------
In article <:SY3...@xds13.ferranti.com>, pe...@ficc.ferranti.com
(Peter da Silva) writes...
>How about the fact that programmers may have better things to do with their
>time than warp code to fit into the windowing universe? I realise that on
>the mac 90% of the programs are 90% user-interface, but that's not always
>the best way to do things. A compiler, for example, really has no business
>calling GetNextEvent *ever*.
And if the user wants to interrupt the compilation mid-compile? You'd better
have some way of finding at least this out. GetNextEvent (or WaitNextEvent)
seems the proper way to do this to me.
You may indeed have to change some of your code to run properly on the Mac. Or
put another way: you may have to change some of your code to put the user in
complete control. The above example as a case in point.
Robert
============================================================================
= gft_rob...@gsbacd.uchicago.edu * generic disclaimer: * "It's more fun to =
= * all my opinions are * compute" =
= * mine * -Kraftwerk =
============================================================================
Path: gmdzi!unido!mcsun!uunet!cs.utexas.edu!rice!uw-beaver!ubc-cs!alberta!
arcsun.arc.ab.ca!calgary!enme.UCalgary.CA!deraadt
From: dera...@enme.UCalgary.CA (Theo Deraadt)
Newsgroups: comp.arch
Subject: Re: Macintosh OS
Message-ID: <1990Jun7.212351.20426@calgary.uucp>
Date: 7 Jun 90 21:23:51 GMT
Sender: n...@calgary.uucp (Network News Manager)
Reply-To: dera...@enme.UCalgary.CA (Theo Deraadt)
Organization: U. of Calgary, Calgary, Alberta, Canada
Lines: 32
Posted: Thu Jun 7 22:23:51 1990
In article <1990Jun6.222126.2...@midway.uchicago.edu>,
gft_rob...@gsbacd.uchicago.edu writes
>In article <:SY3...@xds13.ferranti.com>, pe...@ficc.ferranti.com
(Peter da Silva) writes...
>>How about the fact that programmers may have better things to do with their
>>time than warp code to fit into the windowing universe? I realise that on
>>the mac 90% of the programs are 90% user-interface, but that's not always
>>the best way to do things. A compiler, for example, really has no business
>>calling GetNextEvent *ever*.
>
>And if the user wants to interrupt the compilation mid-compile? You'd better
>have some way of finding at least this out. GetNextEvent (or WaitNextEvent)
>seems the proper way to do this to me.
>
>You may indeed have to change some of your code to run properly on the Mac.
>Or put another way: you may have to change some of your code to put the user
>incomplete control. The above example as a case in point.
And why are signals (esp. unix type signals) not a correct way to handle this?
Calling GetNextEvent() sounds like polling to me.
So, if I wanted to do a large matrix add, I would have to call GetNextEvent()
every couple of rows perhaps. And where do I put GetNextEvent() in my
compiler? I guess I put it in the parser, and it calls GetNextEvent() every
100th token or something like that. For heavily recursive stuff, does this
not seem to get overly messy?
<tdr.
SunOS 4.0.3: /usr/include/vm/as.h, Line 44 | Theo de Raadt
Is it a typo? Should the '_' be an 's'?? :-) | dera...@enme.ucalgary.ca
SunOS 4.0.3: /usr/include/vm/as.h, Line 44 | Theo de Raadt
Is it a typo? Should the '_' be an 's'?? :-) | dera...@enme.ucalgary.ca
Path: gmdzi!unido!mcsun!uunet!samsung!zaphod.mps.ohio-state.edu!mips!sgi!
shinobu!odin!aldur!mattly
From: mat...@aldur.sgi.com (James Mattly)
Newsgroups: comp.arch
Subject: Re: Macintosh OS
Message-ID: <8767@odin.corp.sgi.com>
Date: 8 Jun 90 21:54:26 GMT
References: <1990Jun7.212351.20426@calgary.uucp>
Sender: n...@odin.corp.sgi.com
Reply-To: mat...@aldur.sgi.com (James Mattly)
Followup-To: re: Macintosh OS
Organization: Silicon Graphics, Entry Systems Division
Lines: 70
Posted: Fri Jun 8 22:54:26 1990
In article <1990Jun7.212351.20...@calgary.uucp>,
dera...@enme.UCalgary.CA (Theo Deraadt) writes:
> In article <1990Jun6.222126.2...@midway.uchicago.edu>,
gft_rob...@gsbacd.uchicago.edu writes
> >In article <:SY3...@xds13.ferranti.com>, pe...@ficc.ferranti.com
(Peter da Silva) writes...
> >>How about the fact that programmers may have better things to do with their
> >>time than warp code to fit into the windowing universe? I realise that on
> >>the mac 90% of the programs are 90% user-interface, but that's not always
> >>the best way to do things. A compiler, for example, really has no business
> >>calling GetNextEvent *ever*.
> >
> >And if the user wants to interrupt the compilation mid-compile?
You'd better
> >have some way of finding at least this out. GetNextEvent (or WaitNextEvent)
> >seems the proper way to do this to me.
> >
> >You may indeed have to change some of your code to run properly on the Mac.
> >Or put another way: you may have to change some of your code to put the user
> >incomplete control. The above example as a case in point.
>
> And why are signals (esp. unix type signals) not a correct way to
handle this?
> Calling GetNextEvent() sounds like polling to me.
>
> So, if I wanted to do a large matrix add, I would have to call GetNextEvent()
> every couple of rows perhaps. And where do I put GetNextEvent() in my
> compiler? I guess I put it in the parser, and it calls GetNextEvent() every
> 100th token or something like that. For heavily recursive stuff, does this
> not seem to get overly messy?
> <tdr.
>
Exactly!
Why should the programmer belly-ache about putting the GetNextEvent()
into their program when the compiler could do a simmilar job. Consider using
the pragma() directive in C compilers, (or {$switch+/-} for pascal), to turn
on or off an automatic placement of GetNextEvent, or some equivalent call after
every n lines of code. Or inside a loop (not a time critical one!). Or
inside the basic blocks (for all those compiler fans out there!). This
would seem to release the programmer from putting a GetNextEvent every so often
(which seems to be the basis of everyones complaint) and still gain the
benefits
from calling it.
This approach wins for the programmer who doesn't want to "break" his
train of thought while writing a peice of code. It also wins for the Mac OS
which lets the programmer decide when a context switch would be a good idea
(IMHO, the best reason for Cooperative Multitasking).
Perhaps Apple could set up a variant of GetNextEvent (or WaitNextEvent),
which is optimized for this specific use. Also perhaps the compiler could have
options to specify the parameters which are used for the automatic calls. There
should probobly be a function which is called if the GetNextEvent notices a
UpdateEvt, or a Command-. combination, again configurable through pragma's so
that the response function could be changed in different sections of code.
Personaly I prefer the idea of "Cooperative" Multitasking (although I
would like to have seperate address spaces) because it eliminates many hangups
for OS designers to worry about. (If the application developer can't
write code,
he shouldn't be programming :-) Preemptive Multitasking seems to rape processes
if they don't behave. Preemptive Multitasking was 'designed' when I/O was a
good thing for the scheduler.
Any way seemed like a good idea when I typed it up, enjoy.
--------------------
James Mattly (mat...@aldur.esd.sgi.com)
You actualy think that SGI listens to me? Wow what a concept!
----------------
Path: gmdzi!unido!mcsun!uunet!snorkelwacker!husc6!encore!zelig!jdarcy
From: jda...@encore.com (Mostly Useless)
Newsgroups: comp.arch
Subject: Re: Macintosh OS
Message-ID: <jdarcy.644899889@zelig>
Date: 9 Jun 90 02:51:29 GMT
References: <8767@odin.corp.sgi.com>
Sender: n...@Encore.COM
Lines: 45
Posted: Sat Jun 9 03:51:29 1990
mat...@aldur.sgi.com (James Mattly):
>Consider using
>the pragma() directive in C compilers, (or {$switch+/-} for pascal), to turn
>on or off an automatic placement of GetNextEvent, or some equivalent call
>after every n lines of code. Or inside a loop (not a time critical one!). Or
>inside the basic blocks (for all those compiler fans out there!). This
>would seem to release the programmer from putting a GetNextEvent every so
>often (which seems to be the basis of everyones complaint) and still gain the
>benefits from calling it.
What an amazingly half-baked idea! Oh, sorry. . .I just insulted the bakers
of the world. What you're talking about is placing an absolutely impossible
task in front of the compiler writers (who certainly have enough to worry
about already) in hopes of making life just a *tiny* bit easier for OS and
application developers. There is NO WAY that the compiler can have any but
the foggiest idea concerning which points are "appropriate" for a possible
context switch. The application designer will certainly have a much better
idea, or the OS can allow the user to choose, but the compiler is absolutely
the worst place to attempt a solution.
This brings me to my next point, which I would have let slide if I weren't
posting already. I've heard a lot from the Mac interface folks saying how
"the user is in control". However, long experience with the Mac has taught
me that the application can do pretty much what it damn well pleases. It
would take me all of two minutes to write a Mac program that will spin in
an infinite loop without calling GetNextEvent, forcing the user to reboot.
Hell, I'll save them the trouble; I can just as easily write a program that
immediately reboots the machine. All of this is of course done without
special privileges; the Mac HAS NO IDEA of privileges. With the application
in such complete control, I don't see how anyone can say this gives more
power to the user. My only guess is that the people saying such things
have been fortunate enough to use well-behaved Mac applications and have
never lifted a finger in an effort to write one.
Take *any* preemptive multitasking system as a counterexample (UNIX, Amiga,
VMS, whatever). The user wants to stop a compile or other task, so they
do something to tell the OS. The OS turns around and basically yanks the
application's cord without so much as a please or thank you. "Sorry, bub.
Yer outta here." Thus can even the most ill-behaved applications be tamed.
If you ask me - which you didn't - this is the way to keep control in the
users' hands.
--
Jeff d'Arcy, Generic Software Engineer - jda...@encore.com
Nothing was ever achieved by accepting reality
Path: gmdzi!unido!mcsun!uunet!wang!bu-tyng!three!cory
From: c...@three.MV.COM (Cory Kempf)
Newsgroups: comp.arch
Subject: Re: Macintosh OS
Message-ID: <369@three.MV.COM>
Date: 13 Jun 90 03:03:51 GMT
References: <8767@odin.corp.sgi.com> <jdarcy.644899889@zelig>
Organization: Three Letter Co. Nashua, NH.
Lines: 72
Posted: Wed Jun 13 04:03:51 1990
jda...@encore.com (Mostly Useless) writes:
>This brings me to my next point, which I would have let slide if I weren't
>posting already. I've heard a lot from the Mac interface folks saying how
>"the user is in control". However, long experience with the Mac has taught
>me that the application can do pretty much what it damn well pleases. It
>would take me all of two minutes to write a Mac program that will spin in
>an infinite loop without calling GetNextEvent, forcing the user to reboot.
>Hell, I'll save them the trouble; I can just as easily write a program that
>immediately reboots the machine.
But wait a moment to consider... why would a user buy such a broken program?
And, assuming that the user has purchased the program (or otherwise acquired
it), and has found out about this antisocialness, why would they continue to
run it? Personally, I would send it back.
Which brings up a point that *I* was going to let slide... I made a post
suggesting that a well written *USER* oriented program would check for
events frequently (btw, this is just as true for Unix/X as it is for
MacOS). No sooner had the post cleared my modem then several people
posted such fine examples of *USER* oriented programs as Ray Tracers and
Compilers. Give me a break! The user interface to 90% of the compilers
out there has not changed since the days of punch cards!!! Most would not
notice the difference between running on a Mac and running (walking?) on one
of the old IBM batch mode thingies. And I have yet to see a shrink wrapped
ray trace program. A nice toy for academics, but a waste of disk space
to the avarage user. And they do not have much of a UI either. There is
no real qualitative improvement over:
$JOB RAYTRCE
$INPUT = FOO.RT
$OUTPUT = CONSOLE
Something else to consider: Preemptive Multitasking is a time slicing POLICY.
it is not the only one. It does, however, have the distinction of being the
easiest for an application programmer / compiler writer to deal with, as well
as giving the best OVERALL average wait time in the general case. It is by no
means the best policy in ALL cases.
And one further thing: people who buy computers don't give a ****** about
what hard work programmers have to do. They couldn't care less where the
line is drawn between OS and Application. A well written set of cooperating
tasks will run at least as fast as a set of preemptively scheduled tasks.
On a GUI based system, they will run (as perceived by the user) better. The
Current Application will complete actions for the user and then, while the
user is thinking (i.e. the CPU is idle) do other things. Swapping at event
time when there are no pending events is the best time for such things. There
is no way that a purely preemptive MT system can always preemt at such times.
> With the application
>in such complete control, I don't see how anyone can say this gives more
>power to the user. My only guess is that the people saying such things
>have been fortunate enough to use well-behaved Mac applications and have
>never lifted a finger in an effort to write one.
Consider: the USER is PAYING for the PROGRAMMER to do things right. They
are always free to find a programmer (company, actually) that does.
> The OS turns around and basically yanks the
>application's cord without so much as a please or thank you. "Sorry, bub.
>Yer outta here." Thus can even the most ill-behaved applications be tamed.
>If you ask me - which you didn't - this is the way to keep control in the
>users' hands.
It would seem that Apple (finally) agrees with you... In System 7, the user
can press CMD-Option-ESC and terminate a task.
+C
--
Cory Kempf I do speak for the company (sometimes).
Three Letter Company 603 883 2474
email: c...@three.mv.com, harvard!zinn!three!cory
Path: gmdzi!unido!mcsun!uunet!samsung!munnari.oz.au!sirius.ucs.adelaide.edu.au!
augean!sibyl!ian
From: i...@sibyl.eleceng.ua.OZ (Ian Dall)
Newsgroups: comp.arch
Subject: Multi-tasking, and immunology (was Macintosh OS)
Message-ID: <682@sibyl.eleceng.ua.OZ>
Date: 15 Jun 90 02:04:51 GMT
References: <8767@odin.corp.sgi.com> <jdarcy.644899889@zelig> <369@three.MV.COM>
Reply-To: i...@sibyl.OZ (Ian Dall)
Organization: Engineering, Uni of Adelaide, Australia
Lines: 48
Posted: Fri Jun 15 03:04:51 1990
In article <3...@three.MV.COM> c...@three.MV.COM (Cory Kempf) writes:
>
>... A well written set of cooperating
>tasks will run at least as fast as a set of preemptively scheduled tasks.
>On a GUI based system, they will run (as perceived by the user) better. The
>Current Application will complete actions for the user and then, while the
>user is thinking (i.e. the CPU is idle) do other things. Swapping at event
>time when there are no pending events is the best time for such things. There
>is no way that a purely preemptive MT system can always preemt at such times.
You have totally failed to convince me. For a compute bound task, no
time is any better than any other to swap (assuming swapping is
necessary). Assume we have a number of different interactive
applications in different windows, if the user causes a (keyboard or
mouse) event in a window, a premptive system can get the interrupt and
begin wakeing up the correct process immediately. This might stop
another process at an inopportune time, but who cares? As far as the
perceived speed of the system is concerned it is the speed that the
selected interactive process responds that matters, not that a bit of
overhead might have been saved somewhere. In fact, I would hazard a
guess that a "cooperative multitasking" has precisely the opposite
characteristics to what you suggest. It might be slightly faster on
average throughput but will be *slower* to respond interactively. The
only way it wouldn't be slower interactively is if the frequency of
polling for events is so high that the time spent in the
get_next_event function blows away any reductions in overhead.
I guess this discussion only has a place in comp.arch *if* it
influences the requirements on the hardware. I can't see that it does
really. You don't need a cpu with interrupts if you do cooperative
multi-tasking, but are there any modern machines without interrupts?
The "shared address space is best", hypotheses has architecture
relevance (because you don't need a mmu) but as far as I can see the
two (shared address space and cooperative multi-tasking), are
independent features (or bugs :-) ).
A recent virus plague here caused me to ponder whether *that* might
spell the end of "single shared address space" machines. Part of the
reason that viruses spread so fast on PC's is the plug and pray
software idiom, but the other reason is the total lack of any security
on the machine. I know proper operating systems are not immune, and I
know about the internet "worm", but at least Unix has a security
system to overcome. PC's and mac's are wide open. In effect they have
no immune system. My hypothesis for the week (following the biological
analogy) is that MSDOS machines and macs have aids.
--
Ian Dall life (n). A sexually transmitted disease which afflicts
some people more severely than others.
Path: gmdzi!unido!mcsun!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!
mips!sgi!ka...@trifolium.esd.sgi.com
From: ka...@trifolium.esd.sgi.com (Bruce Karsh)
Newsgroups: comp.arch
Subject: Re: Multi-tasking, and immunology (was Macintosh OS)
Message-ID: <62369@sgi.sgi.com>
Date: 17 Jun 90 23:01:31 GMT
References: <8767@odin.corp.sgi.com> <jdarcy.644899889@zelig> <369@three.MV.COM>
<682@sibyl.eleceng.ua.OZ>
Sender: ka...@trifolium.esd.sgi.com
Reply-To: ka...@trifolium.sgi.com (Bruce Karsh)
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 27
Posted: Mon Jun 18 00:01:31 1990
In article <6...@sibyl.eleceng.ua.OZ> i...@sibyl.OZ (Ian Dall) writes:
>I guess this discussion only has a place in comp.arch *if* it
>influences the requirements on the hardware.
This is comp.arch, not comp.hardware. The software architecture of a
computer system seems to be a lot more important to computer users than
the hardware architecture.
I think we need a lot more discussion of software architecture. Certainly
something is wrong with present ideas of how system software should be
architected. Unix machines and their ilk are expensive and not very
popular (except with programmers). Trying to get work done on them is
painfully slow. There is practically no good end-user software available.
It's been this way for nearly twenty years. If Unix is the present idea
of how system software should be architected, then clearly something is very
wrong.
From the recent traffic on this newsgroup, it looks like the Mac-style
very small architectures are not well received by programmers.
However, they have been very well received by their users though. If
the modern view of software architecture can't account for the success
of this kind of architecture, then there's something very wrong with the
modern view.
Bruce Karsh
ka...@sgi.com
Path: gmdzi!unido!mcsun!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!
brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!aries!mcdonald
From: mcdon...@aries.scs.uiuc.edu (Doug McDonald)
Newsgroups: comp.arch
Subject: Re: Multi-tasking, and immunology (was Macintosh OS)
Message-ID: <1990Jun18.020706.10385@ux1.cso.uiuc.edu>
Date: 18 Jun 90 02:07:06 GMT
References: <8767@odin.corp.sgi.com> <jdarcy.644899889@zelig> <369@three.MV.COM>
<682@sibyl.eleceng.ua.OZ> <62369@sgi.sgi.com>
Sender: use...@ux1.cso.uiuc.edu (News)
Reply-To: mcdon...@aries.scs.uiuc.edu (Doug McDonald)
Organization: School of Chemical Sciences, Univ. of Illinois at Urbana-Champaign
Lines: 38
Posted: Mon Jun 18 03:07:06 1990
In article <62...@sgi.sgi.com> ka...@trifolium.sgi.com (Bruce Karsh) writes:
>
>This is comp.arch, not comp.hardware. The software architecture of a
>computer system seems to be a lot more important to computer users than
>the hardware architecture.
An excellent statement.
>
>I think we need a lot more discussion of software architecture.
I agree
>Unix machines and their ilk are expensive and not very
>popular (except with programmers).
Not all Unix machines are expensive. The most popular, by far, Unix
machines, those using the most popular Unix CPU, the 80286/386/486,
are no more expensive than their PC brethren, because they are the same.
>There is practically no good end-user software available.
>It's been this way for nearly twenty years. If Unix is the present idea
>of how system software should be architected, then clearly something is very
>wrong.
>
The reason there is no good end-user software, except a few public domain
things, is that until recently there was no industry-standard platform
to run binaries on. Now that there is (386 PC clones), that might
(or might not) change. There certainly exists a critical mass of
machines out there. But there needs to be a critical mass of software,
that can be bought at stores in malls.
It will be interesting to see.
To return to the subject of software architecture, I think a good topic
of discussion might be windowing systems. However, there is already
a group (comp.windows.misc) to which it might retire.
Doug McDonald
Path: gmdzi!unido!mcsun!uunet!snorkelwacker!apple!daveo
From: da...@Apple.COM (David M. O'Rourke)
Newsgroups: comp.arch
Subject: Re: Multi-tasking, and immunology (was Macintosh OS)
Message-ID: <42047@apple.Apple.COM>
Date: 18 Jun 90 02:49:36 GMT
References: <8767@odin.corp.sgi.com> <jdarcy.644899889@zelig> <369@three.MV.COM>
<682@sibyl.eleceng.ua.OZ> <62369@sgi.sgi.com>
<1990Jun18.020706.10385@ux1.cso.uiuc.edu>
Organization: Apple Computer Inc, Cupertino, CA
Lines: 42
Posted: Mon Jun 18 03:49:36 1990
mcdon...@aries.scs.uiuc.edu (Doug McDonald) writes:
>Not all Unix machines are expensive. The most popular, by far, Unix
>machines, those using the most popular Unix CPU, the 80286/386/486,
> are no more expensive than their PC brethren, because they are the same.
I disagree, a *useable* PC system is much cheaper than a *useable*
unix system. The large disk requirements for most unix systems are outside
the budget of the average PC user. Although the PC system might be as
cheap the peripheral and support to maintain a useable Unix system is far
and away more expensive than even a top-notch PC system.
But then again who really wants a PC when they could have a Mac ;-)
>
>
>>There is practically no good end-user software available.
>>It's been this way for nearly twenty years. If Unix is the present idea
>>of how system software should be architected, then clearly something is very
>>wrong.
>>
>The reason there is no good end-user software, except a few public domain
>things, is that until recently there was no industry-standard platform
>to run binaries on. Now that there is (386 PC clones), that might
>(or might not) change. There certainly exists a critical mass of
>machines out there. But there needs to be a critical mass of software,
>that can be bought at stores in malls.
>
>It will be interesting to see.
>
>To return to the subject of software architecture, I think a good topic
>of discussion might be windowing systems. However, there is already
>a group (comp.windows.misc) to which it might retire.
>
>Doug McDonald
--
da...@apple.com David M. O'Rourke
"Hey where'd you learn to shoot like that?" ... "At the 7-11."
-- Marty McFly (Back to the future III)
_______________________________________________________________________________
I do not speak for Apple in any official sense.
Path: gmdzi!unido!mcsun!sunic!nuug!hod!rpi!zaphod.mps.ohio-state.edu!
samsung!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry
From: he...@utzoo.uucp (Henry Spencer)
Newsgroups: comp.arch
Subject: Re: Multi-tasking, and immunology (was Macintosh OS)
Message-ID: <1990Jun18.211515.15808@utzoo.uucp>
Date: 18 Jun 90 21:15:15 GMT
References: <8767@odin.corp.sgi.com> <jdarcy.644899889@zelig> <369@three.MV.COM>
<682@sibyl.eleceng.ua.OZ> <62369@sgi.sgi.com>
<1990Jun18.020706.10385@ux1.cso.uiuc.edu> <42047@apple.Apple.COM>
Organization: U of Toronto Zoology
Lines: 16
Posted: Mon Jun 18 22:15:15 1990
In article <42...@apple.Apple.COM> da...@Apple.COM (David M. O'Rourke) writes:
>>Not all Unix machines are expensive. The most popular, by far, Unix
>>machines, those using the most popular Unix CPU, the 80286/386/486,
>> are no more expensive than their PC brethren, because they are the same.
>
> I disagree, a *useable* PC system is much cheaper than a *useable*
>unix system. The large disk requirements for most unix systems are outside
>the budget of the average PC user...
Only if the "average" PC user doesn't run major applications packages; as
soon as he gets ambitious, he runs into the same requirement for lots of
disk and a good backup medium. It's not the Unix market that's driving
the headlong rush to bigger and bigger 5-inch and 3-inch hard disks.
--
As a user I'll take speed over| Henry Spencer at U of Toronto Zoology
features any day. -A.Tanenbaum| uunet!attcan!utzoo!henry he...@zoo.toronto.edu
Path: gmdzi!unido!mcsun!uunet!snorkelwacker!apple!daveo
From: da...@Apple.COM (David M. O'Rourke)
Newsgroups: comp.arch
Subject: Re: Multi-tasking, and immunology (was Macintosh OS)
Message-ID: <42109@apple.Apple.COM>
Date: 19 Jun 90 06:00:36 GMT
References: <8767@odin.corp.sgi.com> <jdarcy.644899889@zelig> <369@three.MV.COM>
<682@sibyl.eleceng.ua.OZ> <62369@sgi.sgi.com>
<1990Jun18.020706.10385@ux1.cso.uiuc.edu> <42047@apple.Apple.COM>
<1990Jun18.211515.15808@utzoo.uucp>
Organization: Apple Computer Inc, Cupertino, CA
Lines: 27
Posted: Tue Jun 19 07:00:36 1990
he...@utzoo.uucp (Henry Spencer) writes:
>Only if the "average" PC user doesn't run major applications packages; as
>soon as he gets ambitious, he runs into the same requirement for lots of
>disk and a good backup medium. It's not the Unix market that's driving
>the headlong rush to bigger and bigger 5-inch and 3-inch hard disks.
A PC with a 40-60 meg hard drive is *big* PC configuration. Sure you can
use more, but even loading up 8-10 *big* pieces of PC software, the OS and
all the associated help files, print drives, and fonts, a 40 meg system is
normally sufficient. Also RAM requirements, while the 640K barrier sucks,
tend to be lower, with a 2 meg PC system again being consider rather large
and overkill for 98% of the PC users....
When was the last time you *wanted* to run a Unix system on a 40 meg HD and
2 megs of RAM, while most people would consider that config a "killer" PC
system, it's hardly adequite for a Unix system.
I still say that although you can run Unix on a cheap 368 clone, there's
nothing cheap or in-expensive about even the most trivial Unix system when
compared with personal computers.
--
da...@apple.com David M. O'Rourke
"Hey where'd you learn to shoot like that?" ... "At the 7-11."
-- Marty McFly (Back to the future III)
_______________________________________________________________________________
I do not speak for Apple in any official sense.
Path: gmdzi!unido!mcsun!uunet!samsung!zaphod.mps.ohio-state.edu!usc!apple!daveo
From: da...@Apple.COM (David M. O'Rourke)
Newsgroups: comp.arch
Subject: Re: Multi-tasking, and immunology (was Macintosh OS)
Message-ID: <42111@apple.Apple.COM>
Date: 19 Jun 90 06:06:26 GMT
References: <42047@apple.Apple.COM> <8767@odin.corp.sgi.com>
<jdarcy.644899889@zelig> <369@three.MV.COM> <682@sibyl.eleceng.ua.OZ>
<62369@sgi.sgi.com> <1990Jun18.020706.10385@ux1.cso.uiuc.edu>
<1990Jun19.014346.12758@oracle.com>
Organization: Apple Computer Inc, Cupertino, CA
Lines: 28
Posted: Tue Jun 19 07:06:26 1990
csimm...@oracle.com writes:
>I disagree. A useable Unix system costs less than $100,000. (File server,
>4GB disk, 32+MB dram, 1Kx1K color workstation with 200MB disk and 16MB
>memory.)
>
>I've yet to see a useable PC.
I think the market place supports me on this one, that there are many
useable PC systems, in fact I believe many people are just the other way
around, they've yet to see a useable Unix system....
I had this discussion MANY time's in college and never got anywhere, but
normally it was with people who couldn't put themselve's in the shoes of a
"real" user to save their lives, and where only concerned about making it
work for themselves rather than helping users benifit from power of having
their own computer... sigh. Programmer's a very very very tiny portion of
the computer community, I'm sure we'd all be pleased if all detroit built
was car's for the indy drives, after all a family car is hardly of any user
to an indy car driver now then isn't. So lets just scrap all the personal
cars in the world, since the only people who should have them are the
professional drivers...
--
da...@apple.com David M. O'Rourke
"Hey where'd you learn to shoot like that?" ... "At the 7-11."
-- Marty McFly (Back to the future III)
_______________________________________________________________________________
I do not speak for Apple in any official sense.
Path: gmdzi!unido!mcsun!uunet!samsung!uakari.primate.wisc.edu!uflorida!
ziggy!usfvax2!tscs!tct!chip
From: c...@tct.uucp (Chip Salzenberg)
Newsgroups: comp.arch,alt.religion.computers
Subject: Re: Multi-tasking, and immunology (was Macintosh OS)
Message-ID: <267D069E.609F@tct.uucp>
Date: 18 Jun 90 16:51:41 GMT
References: <62369@sgi.sgi.com> <1990Jun18.020706.10385@ux1.cso.uiuc.edu>
<42047@apple.Apple.COM>
Followup-To: alt.religion.computers
Organization: ComDev/TCT, Sarasota, FL
Lines: 9
Posted: Mon Jun 18 17:51:41 1990
[Followups to alt.religion.computers]
According to da...@Apple.COM (David M. O'Rourke):
>I disagree, a *useable* PC system is much cheaper than a *useable*
>unix system.
"Useable MS-DOS PC" is an oxymoron.
--
Chip, the new t.b answer man <c...@tct.uucp>, <uunet!ateng!tct!chip>
Path: gmdzi!unido!mcsun!uunet!sugar!splut!jay
From: j...@splut.conmicro.com (Jay "you ignorant splut!" Maynard)
Newsgroups: alt.religion.computers
Subject: Re: Multi-tasking, and immunology (was Macintosh OS)
Message-ID: <B2Y-_JC@splut.conmicro.com>
Date: 19 Jun 90 11:41:57 GMT
References: <62369@sgi.sgi.com> <1990Jun18.020706.10385@ux1.cso.uiuc.edu>
<42047@apple.Apple.COM> <267D069E.609F@tct.uucp>
Reply-To: j...@splut.conmicro.com (Jay "you ignorant splut!" Maynard)
Organization: Confederate Microsystems, League City, TX
Lines: 17
Posted: Tue Jun 19 12:41:57 1990
In article <267D069E.6...@tct.uucp> c...@tct.uucp (Chip Salzenberg) writes:
>According to da...@Apple.COM (David M. O'Rourke):
>>I disagree, a *useable* PC system is much cheaper than a *useable*
>>unix system.
>"Useable MS-DOS PC" is an oxymoron.
Tell that to the millions of people using MS-DOS PCs daily.
Running Unix takes a major hardware investment - at least 2 MB RAM, 100
MB of hard disk, and some sort of tape backup. While each of these is
nice on an MS-DOS system, none is required.
--
Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
j...@splut.conmicro.com (eieio)| adequately be explained by stupidity.
"I don't usually do vicious; +----------------------------------------
I try to stick to depressing." -- Janis Ian, in concert, 6/6/90
Path: gmdzi!unido!mcsun!uunet!munnari.oz.au!sirius.ucs.adelaide.edu.au!
augean!sibyl!ian
From: i...@sibyl.eleceng.ua.OZ (Ian Dall)
Newsgroups: comp.arch
Subject: Re: Multi-tasking, and immunology (was Macintosh OS)
Message-ID: <688@sibyl.eleceng.ua.OZ>
Date: 19 Jun 90 22:53:38 GMT
References: <8767@odin.corp.sgi.com> <jdarcy.644899889@zelig> <369@three.MV.COM>
<682@sibyl.eleceng.ua.OZ> <62369@sgi.sgi.com>
<1990Jun18.020706.10385@ux1.cso.uiuc.edu> <42047@apple.Apple.COM>
Reply-To: i...@sibyl.OZ (Ian Dall)
Organization: Engineering, Uni of Adelaide, Australia
Lines: 24
Posted: Tue Jun 19 23:53:38 1990
In article <42...@apple.Apple.COM> da...@Apple.COM (David M. O'Rourke) writes:
}mcdon...@aries.scs.uiuc.edu (Doug McDonald) writes:
}>Not all Unix machines are expensive. The most popular, by far, Unix
}>machines, those using the most popular Unix CPU, the 80286/386/486,
}> are no more expensive than their PC brethren, because they are the same.
}
} I disagree, a *useable* PC system is much cheaper than a *useable*
}unix system. The large disk requirements for most unix systems are outside
}the budget of the average PC user. Although the PC system might be as
}cheap the peripheral and support to maintain a useable Unix system is far
}and away more expensive than even a top-notch PC system.
I first met unix on a 256kB PDP 11-40 with two rk05's (one fixed and
one removable). From memory a rk05 was 5MB. We thought we were in
heaven when we got a 20MB winchester. Believe it or not this supported
half a dozen users. It ought to run quite happily on a a 640k AT with
a 10MB winchester.
I reckon the reason unix machines are bigger in practice is *because* they
can do more. /etc, /bin and /lib add up to 2MB on this machine and I reckon
that is enough to contain more system services than any messy-dog machine.
--
Ian Dall life (n). A sexually transmitted disease which afflicts
some people more severely than others.
Path: gmdzi!unido!mcsun!uunet!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!
maverick.ksu.ksu.edu!rutgers!mcnc!uvaarpa!murdoch!astsun9.astro.Virginia.EDU!gl8f
From: g...@astsun9.astro.Virginia.EDU (Greg Lindahl)
Newsgroups: alt.religion.computers
Subject: Re: Multi-tasking, and immunology (was Macintosh OS)
Message-ID: <1990Jun19.234651.16389@murdoch.acc.Virginia.EDU>
Date: 19 Jun 90 23:46:51 GMT
References: <42047@apple.Apple.COM> <267D069E.609F@tct.uucp>
<B2Y-_JC@splut.conmicro.com>
Sender: n...@murdoch.acc.Virginia.EDU
Organization: Department of Astronomy, University of Virginia
Lines: 18
Posted: Wed Jun 20 00:46:51 1990
In article <B2Y-...@splut.conmicro.com> j...@splut.conmicro.com
(Jay "you ignorant splut!" Maynard) writes:
>Running Unix takes a major hardware investment - at least 2 MB RAM, 100
>MB of hard disk, and some sort of tape backup. While each of these is
>nice on an MS-DOS system, none is required.
Version 7 Unix does not require these resources. Many more modern
Unixes do not require that much disk space as long as you don't load
in all the utilities, which the other OS you're comparing Unix to
doesn't have. And 2mb of ram costs $150 these days.
Hey, wisner, at least somebody's using your group. Too bad Jay doesn't
know what he's talking about.
--
"Perhaps I'm commenting a bit cynically, but I think I'm qualified to."
- Dan Bernstein
Path: gmdzi!unido!mcsun!uunet!nuchat!splut!jay
From: j...@splut.conmicro.com (Jay "you ignorant splut!" Maynard)
Newsgroups: alt.religion.computers
Subject: Re: Multi-tasking, and immunology (was Macintosh OS)
Message-ID: <JC1-.Y@splut.conmicro.com>
Date: 21 Jun 90 03:08:29 GMT
References: <42047@apple.Apple.COM> <267D069E.609F@tct.uucp>
<B2Y-_JC@splut.conmicro.com> <1990Jun19.234651.16389@murdoch.acc.Virginia.EDU>
Reply-To: j...@splut.conmicro.com (Jay "you ignorant splut!" Maynard)
Organization: Confederate Microsystems, League City, TX
Lines: 27
Posted: Thu Jun 21 04:08:29 1990
In article <1990Jun19.234651.16...@murdoch.acc.Virginia.EDU>
g...@astsun9.astro.Virginia.EDU (Greg Lindahl) writes:
>In article <B2Y-...@splut.conmicro.com> j...@splut.conmicro.com
(Jay "you ignorant splut!" Maynard) writes:
>>Running Unix takes a major hardware investment - at least 2 MB RAM, 100
>>MB of hard disk, and some sort of tape backup. While each of these is
>>nice on an MS-DOS system, none is required.
>Version 7 Unix does not require these resources. Many more modern
>Unixes do not require that much disk space as long as you don't load
>in all the utilities, which the other OS you're comparing Unix to
>doesn't have. And 2mb of ram costs $150 these days.
I spoke from personal experience: that's what it took to make my
PC/AT-clone run Microbug...er...Microport System V/AT. Show me a v7
that's been ported to the 80x86 environment and I'll see how much it
takes.
That AT-clone has grown, too, to 5248K and 162MB.
>Hey, wisner, at least somebody's using your group. Too bad Jay doesn't
>know what he's talking about.
OK, you try running Unix on industry-standard hardware and see how much
resources it takes. I have.
--
Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
j...@splut.conmicro.com (eieio)| adequately be explained by stupidity.
"I don't usually do vicious; +----------------------------------------
I try to stick to depressing." -- Janis Ian, in concert, 6/6/90
Path: gmdzi!unido!mcsun!uunet!attcan!utgpu!utzoo!henry
From: he...@utzoo.uucp (Henry Spencer)
Newsgroups: comp.arch
Subject: size of systems
Message-ID: <1990Jun21.174550.17302@utzoo.uucp>
Date: 21 Jun 90 17:45:50 GMT
References: <8767@odin.corp.sgi.com> <jdarcy.644899889@zelig>
<369@three.MV.COM> <682@sibyl.eleceng.ua.OZ> <62369@sgi.sgi.com>
<1990Jun18.020706.10385@ux1.cso.uiuc.edu> <42047@apple.Apple.COM>
<688@sibyl.eleceng.ua.OZ>
Organization: U of Toronto Zoology
Lines: 14
Posted: Thu Jun 21 18:45:50 1990
In article <6...@sibyl.eleceng.ua.OZ> i...@sibyl.OZ (Ian Dall) writes:
>I first met unix on a 256kB PDP 11-40 with two rk05's (one fixed and
>one removable). From memory a rk05 was 5MB...
No, an RK05 was 2.4MB. (To be precise, 4872 512-byte blocks.) It was
possible to run Unix on one of them, although with little spare space and
no on-line sources or documentation.
Mind you, no modern Unix would fit. That was in the days when the kernel
was (had to be!) under 64KB of text and 48KB of data, and user programs
were under similar restrictions.
--
As a user I'll take speed over| Henry Spencer at U of Toronto Zoology
features any day. -A.Tanenbaum| uunet!attcan!utzoo!henry he...@zoo.toronto.edu