jwbirdsa@phoenix.Princeton.EDU (James Webster Birdsall) (05/08/89)
In article <3718@nunki.usc.edu> sawant@nunki.usc.edu (Abhay Sawant) writes: >I'm pretty certain that the performance which MS-DOS extracts out of >it's hardware could not have been got by writing in C. So writing >MS-DOS in assembly ... > >------------------------------------------------------------------------------- >You're never too old to have a happy childhood. > >ajay shah (213)745-2923 or sawant@nunki.usc.edu >_______________________________________________________________________________ What performance? OK, I guess your point is that it's as fast as it is because it was written in assembly. Perfectly valid... but ask all the programmers who have to deal with writing to the video RAM about how fast it is. :-) [Incidentally, ARE there any parts of DOS which are generally acknowledged as being fast? All I ever hear about are the parts which everybody thinks suck.] -- James W. Birdsall jwbirdsa@phoenix.Princeton.EDU jwbirdsa@pucc.BITNET ...allegra!princeton!phoenix!jwbirdsa Compu$erve: 71261,1731 "For it is the doom of men that they forget." -- Merlin
bright@Data-IO.COM (Walter Bright) (05/09/89)
In article <8197@phoenix.Princeton.EDU> jwbirdsa@phoenix.Princeton.EDU (James Webster Birdsall) writes: <In article <3718@nunki.usc.edu< sawant@nunki.usc.edu (Abhay Sawant) writes: < What performance? OK, I guess your point is that it's as fast as it <is because it was written in assembly. Perfectly valid... but ask all <the programmers who have to deal with writing to the video RAM about how <fast it is. :-) [Incidentally, ARE there any parts of DOS which are <generally acknowledged as being fast? 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! DOS's basic disk I/O is generally considered fast. In fact, I once saw a magazine article where the author went to a lot of trouble trying to duplicate the speed of DOS's COPY C:*.* command. He couldn't do it faster. (Though he might have been merely incompetent! :-)) Also, I've never heard anyone complain about the disk I/O speed and blamed it on DOS. It's always been blamed on: 1. Slow hardware speeds. 2. Should use a (ram hungry) disk cache. 3. Should use non-blocking I/O. The proof of this is that practically no programs go around DOS to do disk I/O for speed reasons.
dmt@mtunb.ATT.COM (Dave Tutelman) (05/09/89)
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 | +---------------------------------------------------------------+
pozar@hoptoad.uucp (Tim Pozar) (05/09/89)
In article <1972@dataio.Data-IO.COM> bright@dataio.Data-IO.COM (Walter Bright) writes: >DOS's basic disk I/O is generally considered fast. In fact, I once saw a >magazine article where the author went to a lot of trouble trying to duplicate >the speed of DOS's COPY C:*.* command. He couldn't do it faster. (Though >he might have been merely incompetent! :-)) >Also, I've never heard anyone complain about the disk I/O speed and blamed >it on DOS. It's always been blamed on: > 1. Slow hardware speeds. > 2. Should use a (ram hungry) disk cache. > 3. Should use non-blocking I/O. >The proof of this is that practically no programs go around DOS to do >disk I/O for speed reasons. I know of several authors and programmes that speficly do an end run around MS-DOS's disk i/o. Things like findfirst and findnext are increadibly slow. Part of the reason that these people are bypassing the system is that they are writing programmes that need to search for on file out of normally 500 to a 1000 files in a subdirectory. On a standard PC (4.77MHz) a find can take several minutes. Tim -- ...sun!hoptoad!\ Tim Pozar >fidogate!pozar Fido: 1:125/406 ...lll-winken!/ PaBell: (415) 788-3904 USNail: KKSF / 77 Maiden Lane / San Francisco CA 94108
randys@hpcvra.CV.HP.COM (Randy Stockberger) (05/12/89)
Timothy L. Kay writes: > That's just it. In my (uninformed) opinion, Microsoft doesn't have > any *architects*. According to the introduction to _Inside OS/2_, > this guy Letwin (the author of the book and "architect" of OS/2) is > somebody Bill Gates met at a hacker conference and hired immediately. > I doubt that he has any formal OS experience. It is all just a hack. ---------- This is uninformed BULL SHIT. J. Gordon Letwin wrote HDOS in the late 70's. This operating system was a big factor in putting Zenith into the computer business. It has features in its first release that didn't make it into MS-DOS until release 2.0 (Installable device drivers, etc) Gordon Letwin knows more about operating systems than 90% of the college profs. Mr. Kay's opinion is indeed uninformed (as is Mr. Kay.) -- Randy Stockberger randys@cv.hp.com