Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!uwvax!uwslh!lishka From: lishka@uwslh.UUCP (Christopher Lishka) Newsgroups: comp.sys.amiga Subject: Re: Mac Multitasking? Hee-hee! Message-ID: <256@uwslh.UUCP> Date: Wed, 31-Dec-69 18:59:59 EDT Article-I.D.: uwslh.256 Posted: Wed Dec 31 18:59:59 1969 Date-Received: Sat, 22-Aug-87 00:45:31 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> Reply-To: lishka@uwslh.UUCP (Christopher Lishka) Organization: U of Wisconsin-Madison, State Hygiene Lab Lines: 108 In article <20164@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >Most Macintosh owners who read these news groups have a perfectly good >idea what multi-tasking is. Agreed, and it too hard to try and explain multitasking to someone without showing it on a machine. However, sometimes I am very surprised at how many people don't know how to use multitasking on Un*x. >Now some substance: Most time-slice mutlti-tasking operating systems >guarantee that every ready-to-run job will get a chance to run, at >least once a time-interval (often a second.) This has the effect of >slowing down interactive performance: the interactive application >doesn't get all of the processor, so there is a lag in its response to >user input. Time sharing multi-user operating systems (like Unix) are >built on the premise that the user will ignore the lag. But, users >used to a single process environment get very picky about the fine >time structure of responsiveness. Example: "If it used to begin to >respond in 3/5ths of a second, and now it takes 4/5ths of a second, >even if it finishes in half the old time, it will feel sluggish." Hmmm...from what I've heard, Un*x's time slice was changed from around 1 second to a lower figure in one of the recent BSD releases, to fix problems like you have described. Anyways, it is true that if you use vanilla time-slicing you find a lag in interactive response if you run more jobs. However, a good priority scheme can alleviate this problem...something like a well-tuned exponential queueing system. However, the key note is that multitasking needs to be well tuned to the machine and purpose. Blanket statements like "Multitasking *always* works well" or "I don't ever want to use multitasking because it slows down interaction" just don't cut it. We are running on a VAX-11/750, and at times have 31 users on it (ouch!). Now, the machine *does* slow down, but because what most of the users are doing is NOT so CPU intensive, one can still work reasonably well on the machine. Of course, the machine will work much nicer if there is only one user on it (me, after everyone else has gone home ;-) . >Here is a problem that neither the current Mac or Amiga have, but may >hurt them both in the future: >Virtual memory interacts poorly with time-slicing and interactivity: >[ Mr. Oster goes on to describe problems with Virtual Memory/Disk > Swapping and Time-slicing ] This is certainly true *if* there is not enough RAM to store the program in memory while the others are running. *However*, given a reasonably good amount of available RAM, the running program will not need to swap out to disk nearly as much. This is helped by the 10%-90% principle (10% of the code runs 90% of the time). Another example: we here at the State Lab have around 8 megabytes of RAM. When I last discussed disk-swapping with our local Un*x-wizard, he told me that we rarely get swaps out to disk because of the 8 megabytes of RAM we have installed (and by rarely I mean that he has only seen the system swap a few times in all of the time he has [visually] monitored it). Like I alluded to above, we run a fairly loaded system. But because of a relatively small investment in a lot of RAM, the system is working close to its peak level. My point is that if you implement virtual memory *or* time-slicing poorly, you will get poor results. If you implement it properly you get good results. Maybe that is why the Amiga does not have virtual memory...there would be too much overhead involved (in hardware and software) to warrant the current need (someone told me about software-implemented virtual memory in Micr*soft Windows, saying he works with it and it is really slow, even on his AT). That is also a good reason (maybe) why Apple didn't include a Multitasking system when they built the Macintosh; it wasn't working well with the Lisa so they decided that they would pass over multitasking in favor of a lower price tag. However, that does not excuse the fact that Apple does not have Multitasking on its Macintoshes now. Multitasking (as proven by the Amiga and other machines such as the AT&T 6300+) is a very realizable goal for personal computers *if*you*do*it*right* ! With the older Macintoshes it wasn't, because as Mr. Oster points out there was not enough memory. But it could be a real goal for current Macintoshes (I think, although I am not sure). The only drawback now is the current Operating System, which is a big drawback. I don't think that what Apple is currently calling "Multitasking" is true multitasking (i.e. you have to switch between processes yourself!). Note that Apple *is* getting true Multitasking with their Mac II's, and IBM is getting it with their OS2's...multitasking is finally coming of age (and the Amiga has had it for a couple years already!). >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. Correct...multitasking is another one of those damned religious issues such as editors or "my computer whips your computer's b*tt!", (or the Pixar debate) that are best left in one newsgroup, and not cross-posted to annoy other newsgroups. [Personally, I don't think that Un*x has that bad of an interactive problem...I've become quite content with it, and prefer the ability to run many programs, along with my fellow workers, than to have a dedicated IBM PC in front of...you can't email very well with an IBM!] >--- David Phillip Oster --My Good News: "I'm a perfectionist." >Arpa: oster@dewey.soe.berkeley.edu --My Bad News: "I don't charge by the hour." >Uucp: {seismo,decvax,...}!ucbvax!oster%dewey.soe.berkeley.edu -Chris -- Chris Lishka /lishka@uwslh.uucp Wisconsin State Lab of Hygiene <-lishka%uwslh.uucp@rsch.wisc.edu \{seismo, harvard,topaz,...}!uwvax!uwslh!lishka