Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!clyde.concordia.ca!nstn.ns.ca!news.cs.indiana.edu!samsung!usc!ucla-cs!ucla-seas!turing.seas.ucla.edu From: plinio@turing.seas.ucla.edu (Plinio Barbeito/) Newsgroups: comp.sys.atari.st Subject: Re: Multitasking Message-ID: <1986@lee.SEAS.UCLA.EDU> Date: 15 Feb 91 14:15:51 GMT References: <1991Feb11.151210.4010@informatik.uni-erlangen.de> <1976@lee.SEAS.UCLA.EDU> <1991Feb14.133758.3687@doe.utoronto.ca> Sender: news@SEAS.UCLA.EDU Organization: SEASnet, University of California, Los Angeles Lines: 92 In article <1991Feb14.133758.3687@doe.utoronto.ca> david@doe.utoronto.ca (David [...] >>system avoids the typical 10-40% overhead on the processor due to the >>kernel having to do its housekeeping (e.g. basically "asking" each >>process "Do you want to run now?"). An 8MHz single-tasking machine >>running a given program would appear to be a 7.2 MHz machine if it had >>multitasking overhead of only 10%. >> >>Since a lot of the time a single-user machine like the ST only needs >>to be running one program, there'd better be a good reason to penalize >>the user with a significant amount of overhead all the time. > >It's not as bad as you make it out to be. First of all, all of the True, as long as a machine is still usable for what you need it for, and doesn't frustrate you because you know it could be done faster, who cares how much CPU time is being used up? I was trying to balance the argument with the little talked about downsides of multitasking -- maybe I overdid it. There are lots of cases in which multitasking will save you time. I decided to point out some in which it doesn't, and found quite a few in the process. Again, I actually prefer to use multitasking, if the slowdown (and other things) aren't so bad as to outweigh the benefits. Mainly, I wanted to debunk any notions that may have existed that multitasking gets you something for nothing; that you could have 10 busy, scrolling screens running side by side in different windows, and that they would all be chugging along at the full-speed that you're used to on your single-tasking machine. >interrupts (mouse handler, etc.) in the ST can slow down any program >as much as or more than a multi-tasking scheduler. The ideal way to The way the mouse was done on the ST happens to be one of the things that I liked most about the original O/S. Machines 10 times more expensive exist that cannot approach the quality of it (the clicking is another story). Yes, even the fast, 12.5 MIPS Sparcs running Unix/X-windows have a 'mushy' feel to the mouse tracking, and a skipping mouse cursor with a painted-on appearance, by comparison. >multi-task is to have the foreground program at full priority, and the >background program(s) at low priority. ie. if you are writing something >in an editor, the editor does not wasted CPU time while it is waiting >for a keystroke, and the compilation process in the background can use >all of the CPU, and the compilation process bides its time until the Not *all* of the CPU. Even though you may not notice it, part of the CPU time has to be going to the taxman, simply because there's a timer interrupting the processor constantly, waking up the scheduler many times a second to check if it is time for another process to run. And this is the *efficient* way to do it. >don't find microemacs sluggish, even when virmf is making a new TeX >font in the background! If you have a slow hard disk, however, any That's how it should be. But a lot of implementations out there are processor (and memory) hogs, and do make you wait for a keystroke. As far as MiNT is concerned, know that you have been spoiled. This product has achieved Unix source near-compatibility, while at the same time imposing what is in my opinion a respectably very low CPU overhead, and a low memory overhead (by comparison) at the same time. Other implementations out there for other machines don't shine so brightly. (I won't name names in the interest of not throwing spoilt apples at other companies, but...) Have you ever used a presumably fast machine that used cooperative multitasking? The 40% overhead figure that I mentioned above would not seem unrealistic to you after using one. So as you can see, it could be worse. It could be a LOT worse. >disk-bound process can slow down all the tasks. However, when I am How's that? With DMA, you'd think a slow hard disk and a fast one would burden you about the same (not much). >running only a single task under MT C-Shell or MiNT, I cannot notice >any speed difference between that and TOS. Could it be possible that MiNT implements a rewrite and speedup of the Bconxxx O/S calls, and that's why typing and printing text on the screen does not seem that slow? Is it just me, or is scrolling actually FASTER under MiNT? plini b -- ----- ---- --- -- ------ ---- --- -- - - - plinio@seas.ucla.edu Putting the Ctrl key under shift; replacing it with CAPSLOCK, is like putting the steering wheel in the trunk, and trying to drive with the spare tire.