Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.sys.amiga
Subject: Re: Apple System 7.0 [ and some 1.4 suggestions ]
Message-ID: <6864@cbmvax.UUCP>
Date: 14 May 89 02:35:34 GMT
References: <17148@usc.edu> <24279@agate.BERKELEY.EDU> <18268@cup.portal.com> <17183@usc.edu> <21814@srcsip.UUCP> <5847@cs.Buffalo.EDU>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Organization: Commodore Technology, West Chester, PA
Lines: 49

In article <5847@cs.Buffalo.EDU> ugkamins@sunybcs.UUCP (John Kaminski) writes:
>In article <21814@srcsip.UUCP> mnkonar@gorby.UUCP (Murat N. Konar) writes:
>>I for one would rather not have my application pre-empted by a background
process
>>in the middle of say a menu selection.  Any one who has used TOPS while a
large
>>file transfer is in progress can attest to the fact that having the interface
>>slow down is a real drag.  (TOPS for those who may not know, is an AppleTalk
>>fileserver system that runs in the 'background')

	That's _exactly_ what can be prevented by the sort of preemptive
multitasking we have on the Amiga.  Menu and user interface operation aren't
slowed down because they run at a higher priority than user tasks.  Since it
is preemptive, whenever it needs to run to handle user input it will, instead
of (as in Multifinder) waiting for the current program to give up the processor,
which may take a while.

>>Anyone who has used Suntools on the Sun's can attest to the horrible things
that
>>can happen when your're trying to get a menu up but the processor is too busy
servicing
>>some other process.

	That's because the User Interface doesn't have priority, because Suns
(and unix in general) are slower at task-switches (on the same hardware), and
because even if the UI process gets a slot, lower-priority tasks can be given
the processor (SunOS isn't a real-time OS).  (Don't think I'm bashing Suns,
I'm writing this on one).

>Another blemish on the Amiga system, performance-wise, is general disk access
>by more than one process.  Thrashing is most evident.  That is just the
>result of poor disk controlling software design.  Anyone doing "concurrent"
>disk accesses on an Amiga floppy knows well that something along the lines
>of disk request buffering coupled with the a periodic application of a seek
>optimization algorithm (elevator for example) would be "to die for."

	Elevator algorithms only help if you have three or more processes
competing for disk access.  Usually on the amiga, you have no more than two
in the situations you site.  The problem is when 2 processes alternate asking
for a small number of blocks.

	Note to developers: your programs will load with less thrashing (when
two things are loaded at the same time) if you use Blink's SMALLCODE and
SMALLDATA options.  Also, the less static and more dynamic structures you
have, the less relocation information needed, and the faster the loads will
go.  These apply when the program is being loaded alone, also.
	
-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup