Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!rutgers!att!mtunb!dmt
From: dmt@mtunb.ATT.COM (Dave Tutelman)
Newsgroups: comp.sys.ibm.pc
Subject: Re: DOS is fast? (Was Re: Why unix doesn't catch on)
Message-ID: <1494@mtunb.ATT.COM>
Date: 9 May 89 11:59:41 GMT
References: <7632@phoenix.Princeton.EDU> <256@jwt.UUCP> <2496@bucsb.UUCP> <274@tree.UUCP> <552@rna.UUCP> <13546@watdragon.waterloo.edu> <3718@nunki.usc.edu> <8197@phoenix.Princeton.EDU> <1972@dataio.Data-IO.COM>
Reply-To: dmt@mtunb.UUCP (Dave Tutelman)
Organization: AT&T Bell Labs - Middletown, NJ
Lines: 46

In article <1972@dataio.Data-IO.COM> bright@dataio.Data-IO.COM (Walter Bright) writes:
>
>The reason the video I/O is such a dog is because of the BIOS, not DOS.
>The BIOS video I/O is so miserably slow that practically any programmer
>can do it faster. Hint: a major reason is that a BIOS function is
>necessary that writes a *string* at a time!

Absolutely right!  A couple of months ago, I posted some fairly
detailed performance measurements.  Among the more striking
results:

	   -	Using the BIOS is slower than almost any other method.
		Assembly-coding screen writes improved performance
		by factors of 8-16, depending on the computer,
		the display hardware, and whether snow elimination
		was necessary.

	   -	The use of an assembly-coded string write function
		improved video I/O speed by factors of 2-6.

Since the major theme of this discussion is "why doesn't UNIX catch on",
it's worth noting that my measurements were motivated by some home
hacking on a video I/O library that would be portable among environments
(DOS and UNIX being the two that hold my interest).  I'm convinced of
the rightness of "code in C, then tune in assembler"; it's the best way
to develop programs (not only for portability, but for quality and
maintainability).  Since low-level stuff like screen I/O is a known
performance bottleneck, I decided to start there.  There are
opportunities for performance enhancements using machine-and-system-
specific code without hurting overall application portability, IF:
   -	You keep the system-specific stuff in library routines.
	The functions in the library must be very carefully defined
	to keep them generic.
   -	You choose to apply the special techniques to the 2% of the
	code that takes 80% of the cycles.  You can make this choice
	by measurement, or by experience with similar applications.

By judicious and imaginative application of these principles, you
can achieve "excellence" as high performance and near-portability.

+---------------------------------------------------------------+
|    Dave Tutelman						|
|    Physical - AT&T Bell Labs  -  Middletown, NJ		|
|    Logical -  ...att!mtunb!dmt				|
|    Audible -  (201) 957 6583					|
+---------------------------------------------------------------+