Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!ames!ptsfa!ihnp4!cuae2!killer!elg From: elg@killer.UUCP (Eric Green) Newsgroups: comp.sys.amiga,comp.sys.mac Subject: Re: Mac Multitasking? Hee-hee! Message-ID: <1373@killer.UUCP> Date: Sat, 22-Aug-87 03:34:05 EDT Article-I.D.: killer.1373 Posted: Sat Aug 22 03:34:05 1987 Date-Received: Sun, 23-Aug-87 12:59:37 EDT References: <20164@ucbvax.BERKELEY.EDU> Organization: Bayou Telecommunications Lines: 82 Xref: mnetor comp.sys.amiga:7672 comp.sys.mac:5877 in article <20164@ucbvax.BERKELEY.EDU>, oster@dewey.soe.berkeley.edu (David Phillip Oster) says: > Most Macintosh owners who read these news groups have a perfectly good > idea what multi-tasking is. After all, the software that hosts "news" > generally runs on big, multi-tasking machines. So, Amiga owners, you > don't have to keep explaining how wonderful it is. Unix is only barely multi-tasking. Unix multi-tasking is basically just an afterthought thrown in to answer the question "There has GOT to be a better way to do background jobs than the way Multics does them!" (note that Unix started out as a Multics knock-off -- I have used Multics before, and background jobs are a pain in the a$$ with Multics). Berkely BSD4.2 is a bit more multi-tasking than Sys V, because you can pop jobs to and from the background. Shells running inside of Emacs and Jove windows is even closer, because you can then even interact with two programs at one time. Still, it's nothing compared to a real windowing interface on a bit-mapped screen... hmm, you say you use a Sun, so you should know that (altho I bet that your Sun is underequipped -- probably not enough memory, and slow disk drives, makin paging painful). > 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. Note that other process's usage of CPU time has nothing to do with response time... they only use CPU time when you're not typing, when you're typing, you have all of the CPU (because each character generates an exception and task switch to your process). It's task switch latency that is the problem. While Unix and most other mainframe OS's have a LOT of state to switch at process switch time, AmigaDOS basically just has to swap in the new registers and new program counter (no MMU setup, etc). On a single-user system, with your interactive processes set to a higher priority than your background processes (e.g. "C" compile), there IS no delay (try typing faster than the task switch latency on an Amiga -- it just ain't done). In multi-tasking terms, Amiga processes are VERY "light-weight". In other words, AmigaDOS is not Unix, and just because heavily-loaded Unix systems are slow to respond, doesn't mean that AmigaDOS is. > Pauses, lags, and unpredictable response time all contribute toward > making even a fast system seem slow. Apple had a multi-tasking > operating system back in '81. It was called the "Lisa Office System", > and suffered from all of the responsiveness problems I've outlined. > > 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. I think I just did -- as I just said, the problem isn't the time used by other tasks, but, rather, task switch time. The actual task-switch algorithm may have something to do with it, too, although there's nothing spectacular about the Amiga's besides that it's simple and fairly fast. Unix and VMS both have to swap in a lot of user state and page in their working set (as you mentioned), and I'm not familiar enough with the Lisa to make any comments about it -- unlike certain Macintosh people who are QUITE willing to comment about a machine that they know nothing about :-). But do note that Unix really isn't THAT sluggish, with adequate memory and disk drives -- I can't tell the difference between 1 user (me), at 4am, and 20 users at 9am, on the Pyramid 90x machines at school. With 25 it's slow, with 30, it's nightmarishly slow. Maybe the Unix and VMS machines you are used to are overloaded and/or underequipped? Anyhow, task switch time on the Amiga is a pitifully small amount of time (someone else, with the System Performance Monitor, will have to back me up on this one), and thus by the time your hand is rising from the key, the task has already responded to the keystroke. The only time I've ever seen an Amiga sluggish was when I had 30-40 "dotty windows" going, and started trying to move the windows around and resize them... 10 seconds to put the window in its new location. The actual interaction of grabbing the window and hauling it to where I wanted it was no problem, I guess that the interactive process runs at a higher priority than the process of actually moving the window. Note that "dotty windows" is a CPU-based process that just generates random numbers to randomly place dots inside its window... -- Eric Green elg%usl.CSNET Ollie North for President: {cbosgd,ihnp4}!killer!elg A man we can believe (in). Snail Mail P.O. Box 92191 Lafayette, LA 70509 BBS phone #: 318-984-3854 300/1200 baud