Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!uunet!cbmvax!jesup
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.arch
Subject: Re: Killer Micros and vectorized code
Message-ID: <10285@cbmvax.commodore.com>
Date: 21 Mar 90 01:58:01 GMT
References: <00933EBB.E972FCA0@KING.ENG.UMD.EDU> <51771@lll-winken.LLNL.GOV> <100598@convex.convex.com> <52661@lll-winken.LLNL.GOV> <1990Mar19.234839.13829@Neon.Stanford.EDU>
Reply-To: jesup@cbmvax (Randell Jesup)
Organization: Commodore, West Chester, PA
Lines: 44

In article <1990Mar19.234839.13829@Neon.Stanford.EDU> philip@pescadero.stanford.edu writes:
>In article <00933EBB.E972FCA0@KING.ENG.UMD.EDU>, sysmgr@KING.ENG.UMD.EDU
>(Doug Mohney) writes:
>
>> If shared resources are such wonderful critters, how come multiuser Macs
>> aren't popular? Or '386es? You could conceivably hang multiple terminals
>> from a '386 or '486 box, but I haven't heard of people rushing out to do so.
>
>Predictable response time...This is also (one of the reasons, anyway) why
>Apple does not support pre-emptive multi-tasking. I'm using a 16Mbyte
>DECstation 3100 and despite the faster processor, it doesn't compare with
>a 68030 Mac on user interface reponsiveness. And the DECstation is hardly ever
>used by other users. Moral of the story? A multi-tasking OS with virtual memory
>etc. has its price.

	You're arguing a deficiency of most Unixes, not of multi-tasking
per se.  A good counter-example is the Amiga - preemptive multitasking but
provides excellent response time even on a lowly 68000.  Most Unixes are
not optimized for user response time, their schedulers just weren't designed
with that as a major consideration.  On an Amiga, the highest-priority task
gets 100% of available cycles, or round-robins with tasks of the same
priority, on a many-times-per-second basis.  Combined with interrupt and
DMA driven IO, this produces very fast user response times.  Light-weight
tasks (faster task-switching) helps here also.

	I suspect the main reason Apple hasn't gone preemptive is that their
system was designed so that preemption would be a massive problem, at best.
All those "low-memory-globals", etc that programs modify  would cause major
havoc to support, or require massive changes of the "rules", making most
applications that had been written correctly become "broken".

	Those of us in the micro market often have to bow and scrape to
the Great God of Compatibility.  :-(  We here at Commodore have been stuck
with our own early design decisions in some cases.

	There are other ways to improve user response time, most of them
"classical".  Stratus VOS (last I looked) bumped the priority of a task that
just got input from a user temporarily.  This improves the "feel" of 
responsiveness.

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Common phrase heard at Amiga Devcon '89: "It's in there!"