Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!columbia!rutgers!lll-lcc!ames!ucbcad!ucbvax!jade!eris!mwm
From: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer)
Newsgroups: comp.sys.amiga,comp.sys.mac
Subject: Re: Mac Multitasking? Hee-hee!
Message-ID: <4793@jade.BERKELEY.EDU>
Date: Wed, 31-Dec-69 18:59:59 EDT
Article-I.D.: jade.4793
Posted: Wed Dec 31 18:59:59 1969
Date-Received: Fri, 21-Aug-87 07:14:23 EDT
References: <6565@eddie.MIT.EDU> <2742@hoptoad.uucp> <3638@cit-vax.Caltech.Edu> <2758@hoptoad.uucp> <4537@videovax.Tek.COM> <20164@ucbvax.BERKELEY.EDU>
Sender: usenet@jade.BERKELEY.EDU
Reply-To: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer)
Organization: Missionaria Phonibalonica
Lines: 80
Xref: mnetor comp.sys.amiga:7545 comp.sys.mac:5704

I've been dealing with this by mail (to avoid contributing to the
mcibtyc stuff), but David asked a legit question, which I happen to
have a good answer to.

In article <20164@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes:
<Virtual memory interacts poorly with time-slicing and interactivity:
<If you have time-slice multitasking, there will often be big low priority
<jobs running in the background, while there is an interactive job
<responding to the user. As the user stops to think, the interactive
<job has nothing to do, so the background job gets most of the CPU. As
<the background job runs, it pages in its working set, and as the
<background job is paged in, the interactive job is paged out.

No, that wasn't the legit question. Just wanted to point out that
swapping systems (say, v6 Unix on a PDP-11/70) have a similar problem.
The interactive jobs get swapped out, and you get that 3-4 second
pause while they load in from disk and restart.

This isn't really a problem of VM vs. multitasking, it's a problem of
overloading the machine. Without VM, those extra tasks will swap
instead of page. Without swapping or vm, those extra tasks just don't
happen (not enough memory to load them).

As you go from fully resident to swapping to vm, you loose a little
performance as you push the macchine to the edge of the capabilities
of the simpler system. But you get performance beyond that edge,
albeit in a degraded mode. Which you want depends on your applications
and budget.

<Amiga fans can help not by explaining why multi-tasking is good, but
<by explaining how the Amiga can do multi-tasking without suffering
<from the interactive response problems that plague Unix, VMS, and that
<plagued the Lisa.

That was the legit question. I don't know about the LISA, but I can
explain why the Amiga does a lot better than Unix or VMS. Both Unix
and VMS have floating priority for processes. This attempts to see
that each process gets a fair (however you define fair) portion of
cpu. To do this, you have to recalculate the priorities every so
often. You also have to keep track of the amount of CPU time each
process eats, etc. All of this gets expensive.

On the other hand, the amiga keeps a fixed priority for each task. All
that overhead vanishes. Of course, the user has to do some work on
setting priorityies for his tasks, but that's nominal most of the
time.

As for pauses & etc. bothering you on Unix & VMS, you ought to run on
a well-tuned unix or VMS system, carrying a reasonable load. It's
quite different than you find running either on the typical university
machine, or on a system out of the box.

BTW, claiming that it was the multi-tasking that killed the Lisa (aka
the Mac XL) seems to be a bit of post hoc, ergo propter hoc. After
all, Apple had another machine die in that same time frame, and it
wasn't multitasking. I suspect that pricing had more to do with either
than multitasking or lack thereof.

<The Macintosh has always had event-driven multi-tasking, as opposed to
<time-slice. I have written many programs that run as background tasks.
<It is just that on the Mac, the interactive application must
<explicitly give up control (which it only does at times that are not
<critical to the perception of responsiveness.) All the major Macintosh
<applications do give up control to background tasks. To see this, run
<my "Menu Clock". If the colon between the hour and the minutes display
<blinks, then the application is giving up control to the clock.

Comes the $64 question: Does all include C compilers waiting on disk
IO, and similar things?

Also does your menu clock have any magic code because it's a
background application? My Amiga menu clock doesn't - it's just a
stock application, no magic at all.

	<mike
--
Round about, round about, in a fair ring-a.		Mike Meyer
Thus we dance, thus we dance, and thus we sing-a.	mwm@berkeley.edu
Trip and go, to and fro, over this green-a.		ucbvax!mwm
All about, in and out, over this green-a.		mwm@ucbjade.BITNET