NJ_GOKEMEIJE@FANDM.BITNET (06/18/91)
From: BGBIRD::NJ_GOKEMEIJE 17-JUN-1991 13:41:42.82 To: INTR CC: NJ_GOKEMEIJE Subj: re:RE: difference between 7.0 and amiga multitasking In article <cg.1963@ami-cg.UUCP> Chris Gray. writes: >In article <1991Jun14.154041.15151@world.std.com> awm@world.std.com writes: > >[stuff about register save/restore deleted] > >>> I think he might be mixing memory with registers. >> >>This seems likely. Unless you have virtual memory, you can only run as many >>applications as will fit in main memory. However, most machines these days >>have enough space for a large number of applications to run at once, and >>the speed at which you can switch between them definitely depends on the >>operating system. > >Another significant factor is how much of the operating system state needs >to be saved/restored on a task switch. Since the Amiga's Exec was designed >with task switching in mind, this is a relatively simple affair (not much >more than moving a couple of pointers). I recall reading an old article in >Byte, however, that said that one of the problems that MultiFinder has is >that the Mac's OS has a LOT of state that has to be manually preserved when >switching tasks. Basically, anything that is task-specific and at a fixed >location must be entirely copied out and saved, then the stuff for the new >task copied back in. Mac guru's could likely expand on this. > >It really doesn't have too much effect, however, unless you try to switch >tasks too often. If the switching is at a human speed, you won't likely >notice it on a 68020 or higher. At 100 times a second, you might. > >-- >Chris Gray alberta!ami-cg!cg or cg%ami-cg@CS.UAlberta.CA > In a way you are right, if the user wants to switch from one program to another, the mac is only seconds slower than the amiga. (because at activation time, all the windows are brought to front and are refreshed.) The big difference is that on a mac, the frontmost program gets all the time in wants, and has control over how much time it gives to other programs. This is not like the amiga, where the tasks priority determines the timesharing. If you use the computer primarily for dtp orso, where the computer usually runs idle for 80% if the time anyway, the two systems work very similar. But if you have the computer do a lot of work, like making a back-up, mathematical calculation, ray-tracing, mandelbrot series etc, it is really nice that you can give that program a low priority, so that you can do other stuff, like editing orso at the same time, without noticing that the computer is working as fast as it can. Printing is a good example. Background printing on a MAC is slower because it gets less time. forground printing makes you wait. Printing on an amiga is always as fast a possible, except if the user wants the cpu for a program with higher priority. THere is no diffence between a main program and background programs. Hopes it helps. Nils Gokemeijer (NJ_GOKEMEIJE@FANDM.bitnet)
dant@ryptyde.UUCP (Daniel Tracy) (06/18/91)
Responding to the following: "The big difference is that on a mac, the frontmost program gets all the time in wants, and has control over how much time it gives to other programs. This is not like the amiga, where the tasks priority determines the timesharing." You're wrong. There's nothing special about the frontmost app. The OS only gives the frontmost app more processing power because it has to do user I/O. It doesn't have any more control than any other program.
rjc@wookumz.gnu.ai.mit.edu (Ray Cromwell) (06/19/91)
In article <65@ryptyde.UUCP> dant@ryptyde.UUCP (Daniel Tracy) writes: >Responding to the following: > >"The big difference is that on a mac, the frontmost program gets all the time >in wants, and has control over how much time it gives to other programs. >This is not like the amiga, where the tasks priority determines the >timesharing." > >You're wrong. There's nothing special about the frontmost app. The OS only >gives the frontmost app more processing power because it has to do user >I/O. It doesn't have any more control than any other program. No, there is definately something special about the front most app. It can control the CPU for a long as possible. What would this do on a Mac? main() { int foobar; for(;;) foobar++; } My guess is, this program would bring the machine down if it was in front. -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /
dant@ryptyde.UUCP (Daniel Tracy) (06/19/91)
Responding to the following: ">You're wrong. There's nothing special about the frontmost app. The OS only >gives the frontmost app more processing power because it has to do user >I/O. It doesn't have any more control than any other program. No, there is definately something special about the front most app. It can control the CPU for a long as possible." No, you're wrong. ANY application, background or foreground, can control the CPU as long as it wants! :-) If background apps didn't have control over how much CPU time they get, it would be a lot closer to preemptive multitasking.
kdarling@hobbes.catt.ncsu.edu (Kevin Darling) (06/19/91)
>>>The big difference is that on a mac, the frontmost program gets all the >>>time it wants, and has control over how much time it gives to other >>> programs. This is not like the amiga, where the task's priority >>> determines the timesharing. >> >>You're wrong. There's nothing special about the frontmost app. The OS only >>gives the frontmost app more processing power because it has to do user >>I/O. It doesn't have any more control than any other program. > >No, there is definately something special about the front most app. >It can control the CPU for a long as possible. True, but that's not "special"... as _any_ application running, even in the background, can keep the cpu as long as it wishes, once it gets control. What _is_ "special" about the Mac foreground application is that either a non-null event or a sleep timeout will always return control to the _front_ app (once the backgrnd app allows it). That's not true for any other app. Kind of a wimpy definition, but there you have it :-). > What would this do on a Mac? > main() > { int foobar; for(;;) foobar++; } > >My guess is, this program would bring the machine down if it was in front. Yes. Something to note tho: in certain situations all scheduling methods degrade into looking like "something else" :-). For example, if the above program had the highest priority on an Amiga, you'd also get lockup. For that matter, to any Amiga program running with a lower priority, its view of the world above it is that of a cooperative multitasking system... because it only gets to run when higher priority tasks _allow_ it to, by their doing IO or otherwise giving up time voluntarily. But that may get us into the realm of aging vs non-aging discussions, and we already went thru that six months ago, didn't we :-) :-). cheers - kevin <kdarling@catt.ncsu.edu>
peter@sugar.hackercorp.com (Peter da Silva) (06/20/91)
In article <330863744000293E@FANDM> NJ_GOKEMEIJE@FANDM.BITNET writes: > In a way you are right, if the user wants to switch from one program to > another, the mac is only seconds slower than the amiga. (because at > activation time, all the windows are brought to front and are refreshed.) "only" seconds slower doesn't sound too bad. But that's the difference between "faster than you can detect" (i.e., a few milliseconds) and "slow enough to drive you crazy". I do work on Macs as infrequently as possible, because this sort of thing is always getting on my nerves. It's as bad as running 30 users on a VAX 780. -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"