🚀 go-pugleaf

In article <> 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. 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.

No, there is a *major* difference.  Consistentley in this mini-war the
incorrect comparison has been made between the Amiga and *multiuser*
computers like the vax I will upload this article to.

The Amiga is *multitasking*, *single-user*.  This has a lot of implications,
many positive, {many,some,a few} negative.


>Now some substance: Most time-slice multi-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:

With the *multiuser* computer you don't have control.  Unless you are blessed,
you get as much chance at the CPU, memory and disk bandwidth as everyone
else.  With my Amiga I have *complete control*.  First off, there are no
other users that can run tasks without my approval.  I chose what is loaded,
and what is running.  Taking a look at the task-monitor I have 22 tasks
loaded.  Three will use CPU as available.  The editor (DME) gets time
*whenever* it wants.  The assembly (finished now) would get any cycles
left over, and the ray-trace gets whatever the assembler can't use (due
to IO operations such as disk seeks, DMA reads, whatever)

This is *not* complex, and while I know the details, I don't need to
worry about them.  It is even less complex with a little toy I wrote
and am testing at the moment.  It's called "auto-pri" and injects a
boost of priority into whatever task/window you click into.
))))							   ((((
)))) With that toy, my interactive task *never* bogs down. ((((
))))							   ((((
When I click out of my *still* recalculating spreadsheet, and into the
text editor, the spreadsheet is not longer "interactive" and no longer will
take time away from the editor, which is.  All auto-magic.


>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."

Right.  User responsiveness is a critical issue.  That is why I don't
_want_ a multi-user computer.  68000's or 68020's are cheap enough
to give each user one... and then network them all together.  Mac,
IBM (mouth-soap :-), Amiga, whatever.  This is the way to go.


>Here is a problem that neither the current Mac or Amiga have, but may
>hurt them both in the future:  [virtual memory]

Right.  You can see the effects already on the Mac by using memory in
such a way as to cause all the "purgable" items to be purged, only
to be brought back in a few mements later.  Newer Mac software does not
suffer here near as much... this problem is on it's way out.  (of course,
gobs of memory helps :-)
You can cause thrashing on the Amiga also if you try real hard.  Just
keep opening and closing disk-loaded fonts and libraries while requesting
large amounts of memory.

-----
|\ /|  . Ack! (NAK, EOT, SOH)
{o O} . 
( " )	bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce
  U	Poet:   "To be, or not to be?"
	Hacker: "$ff"