Xref: utzoo comp.sys.ibm.pc:28750 comp.sys.amiga:33741
Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!uflorida!ukma!rutgers!mcnc!rti!bcw
From: bcw@rti.UUCP (Bruce Wright)
Newsgroups: comp.sys.ibm.pc,comp.sys.amiga
Subject: Re: OS/2 vs AmigaDOS
Summary: some ideas on performance
Message-ID: <2954@rti.UUCP>
Date: 13 May 89 16:00:28 GMT
References: <2134@iitmax.IIT.EDU> <5625@microsoft.UUCP> <5664@microsoft.UUCP> <2649@ssc-vax.UUCP>
Organization: Research Triangle Institute, RTP, NC
Lines: 74

In article <2649@ssc-vax.UUCP>, coy@ssc-vax.UUCP (Stephen B Coy) writes:
> What about CPU overhead.  Recently I checked out the April issue of
> MIPS magazine.  In it they review a few 25Mhz 386 machines.  In
> doing their benchmarks they test the systems running 3 different
> OS's; DOS, Xenix, and OS/2.  Looking at the benchmark results I get
> the impression that system performance under OS/2 is about 40% less
> than under DOS.

I haven't seen the MIPS issue that you refer to, and I haven't done any
benchmarks on OS/2, but there are a few things you have to be very
careful about when you read "benchmark" articles from the general press:

    1)	In comparing a multitasking and a singletasking operating system,
	it is not fair to compare the multitasking system running several
	{jobs, tasks, processes depending on the OS terminology} unless
	the tasks are completely heterogeneous.  For example, a mix
	consisting of the classical CPU-bound "soak" job, a database disk
	thrasher, and a terminal I/O bound text editor.  If you have
	several tasks competing for the same resource it isn't really
	very surprising that they can't get that resource to do more than
	one task can get it to do!  This is especially true of disk drives,
	where moving the disk arm can cause a BIG time penalty and make
	two task doing disk I/O more than twice as slow as one.  This point
	seems to elude many of the people who write "benchmark" articles
	for the popular press.

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

    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.

    4)	If they are comparing OS/2 using the Presentation Manager then I
	expect it would be slower ... without significant hardware assists
	it's hard for a graphics based system to compete with a text based
	system.

    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.

Having said all this I must admit that my experience with OS/2 is limited;
a couple of us played around with it for a couple of days a while back to
get a feel for whether it would be useful for some projects we were thinking
about.  My impression at the time (this was before the Presentation Manager)
was that it was not unreasonably slow - 40% sounds awfully high, well within
human perceptual ability to detect for functions which take any amount of
time.  This was not on any super machine, something like a 12MHz '286, and
for the most part it didn't feel that different from MS-DOS in terms of its
general throughput and responsiveness.  Some things were perhaps a bit
slower, and others perhaps a bit faster, but subjectively a 40% slowdown
sounds unreasonable.  We rejected it for other reasons - primarily because
the complexity of the system service interface did not justify the benefits
for our application (which was pretty special-purpose).

Looking at this I realize it's longer than I intended - sorry about that.
Maybe someone who has done more scientific benchmarking on the system can
address the specific questions about the actual speed of OS/2.

						Bruce C. Wright