Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!POSTGRES.BERKELEY.EDU!dillon
From: dillon@POSTGRES.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: OS/2 vs AmigaDOS
Message-ID: <8905132124.AA27712@postgres.Berkeley.EDU>
Date: 13 May 89 21:24:42 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 78

:    2)	In general, you should not expect that the multitasking system will
:	run equally fast as the single tasking system given the same amount
:	of memory.  IF the single tasking system (or the application) can
:	do things like increase its disk cache or otherwise take advantage
:	of the larger amount of memory, the single tasking system will win.
:	(on the other hand, MS-DOS is really not all that intelligent about
:	taking advantage of memory to increase speed - though some programs
:	that run under it are).

	This above is a different issue alltogether and not related to
multi-tasking / single-tasking at all.  Since when can't a task in a 
multi-tasking system tell the system (if the system supports it) that it 
wants a cache to be arranged differently?  The point is that this is a
function of whether the OS has the capability, not if the OS is multi-tasking.  

	you might be talking about this fact:  In a single-tasking system
people can generally write programs which bypass the OS.  This is not 
considered a good thing, by the way.

:    3)	What you are buying with multitasking is the ability to use several
:	resources at once (like run a compile in the background while you
:	edit a file in the foreground) and (possibly, depending on your
:	application) an ability to have several tasks waiting for various
:	events.  All this does take memory, and some CPU time.  The hope is
:	that by allowing different processes to complement their use of
:	resources that more total work can get done;  but you can almost
:	always set up pathological cases.

	I would put it slightly differently.  Multitasking gives the computer 
the capability to fully utilize all its resources.  Coupled with DMA and other
hardware assist mechanisms, one can usually run all the resources
simultaniously at 100% efficieny.  For example, you could run a disk bound 
program and a CPU bound program simultaniously and they would both run at 
FULL speed. In effect, twice as fast as a single tasking system could ever
possibly do it.

	And here, I should mention that the term 'resource' as used by
Bruce and I here refers to anything modular:  Disk IO, terminal IO, one or
independant program, memory, etc...  For example, running a text editor and
a CPU bound program still results in nearly 100% efficiency for both because
the CPU bound program will still get 95% of the CPU and the user will still
see relatively quick response to typing in the editor.

	Whereas, in a single tasking system you could run only one program,
say the editor, and 95% of the CPU would be wasted.  Or run only the CPU
bound program and you have to wait for it to finish before you can startup
the editor.

	Three way example:  You are running three tasks. (1) CPU bound program,
(2) DISK bound program, (3) text editor.  All three will run at nearly 100%
efficiency.... how close you get depends on other factors such as DMA, etc...
on *real* UNIX machines the above scheme would run at essentially 100%
efficiency (each task would run as fast as if it were the only task in the
system).

	Other examples don't really count.  Running two CPU bound programs
results in each going at half speed... the same as for a single tasking 
system.  Running two disk bound programs is quite different... for instance,
if you have 20MB of disk cache you could quite conceviably run the disk
bound programs nearly at full speed (or they become CPU bound programs).
On the Amiga, running two disk bound programs will run at a little less
than half speed... it depends on the DMA capabilities and the manner of 
access by the programs.

:    5)	It is quite possible for a benchmark to home in on a particular
:	bottleneck on the system and make the system look much worse than
:	it would look in a real environment.  Many of the authors of the
:	benchmark "results" that you see in magazines don't seem to have
:	a very good grasp of this.

	Yes, absolutely.  For instance, a sequent might have 12 processors
but most benchmarks use only one.  Never mind the fact that it takes 20
compiles running simultaniously to bring the load average on the machine to
1.00!

>						Bruce C. Wright

				-Matt