Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!sdcsvax!ucbvax!hoptoad!farren
From: farren@hoptoad.UUCP
Newsgroups: comp.sys.mac,comp.sys.amiga
Subject: Re: Mac Multitasking? Hee-hee!
Message-ID: <2762@hoptoad.uucp>
Date: Mon, 17-Aug-87 03:05:41 EDT
Article-I.D.: hoptoad.2762
Posted: Mon Aug 17 03:05:41 1987
Date-Received: Tue, 18-Aug-87 01:53:40 EDT
References: <6565@eddie.MIT.EDU> <2742@hoptoad.uucp> <3638@cit-vax.Caltech.Edu> <2758@hoptoad.uucp>
Reply-To: farren@hoptoad.UUCP (Mike Farren)
Organization: Nebula Consultants in San Francisco
Lines: 43
Xref: utgpu comp.sys.mac:4997 comp.sys.amiga:7062

In article <2758@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
> You don't need time-slicing with a notebook and pen,
>and for 95% of the things on the Mac you don't need it, either.  For the
>remaining 5%, MultiFinder makes it pretty easy to write them so they can run
>in the background, even in current versions.
[...]
>For computation-intensive processing, presumably you
>don't want to slow things down to that extent anyway, whether through
>synchronous or asynchronous interruptions.

An example:  I had a job which required a large amount of analysis on a
huge (20+ Megabyte) data set.  The particular analysis required pretty
much forced an incremental analysis; that is, the results of the first
analysis were fed as input to the secondary analysis processes, and the
results of those to the third, etc.  There were about eight iterations
required for the complete analysis, and the intermediate results, when 
totaled, occupied considerably more than 50 Megabytes.  There was also
the problem that each of the analysis steps needed to be checked for
accuracy, and due to timing constraints, these checks pretty much had to
be made against the original data.  The way I did it was to run each analysis
step as a sub-process, checking it's output for correctness, and then
piping that output to the next series of analyses, once the particular
analysis had been made correct.  Without the ability to run ALL of the
currently correct analysis steps in parallel, while simultaneously
editing, recompiling, and checking the analysis sub-programs, the task 
would have taken much, much longer than it did, not to mention taking
up much more of the disk space than I was allocated.

The value of true multi-tasking is simply that most programs are NOT 
particularly CPU intensive, but spend large amounts of time waiting for
I/O.  Given this, what conceivable value can there be in allowing an I/O
bound process to hang up the entire system?  Or, for that matter, 
requiring the program itself to determine when it is safe to let the system
run another process?  That's just a slightly more sophisticated version
of busy-waiting, and strikes me as a BIG waste of useful processor time.



-- 
----------------
                 "... if the church put in half the time on covetousness
Mike Farren      that it does on lust, this would be a better world ..."
hoptoad!farren       Garrison Keillor, "Lake Wobegon Days"