Xref: utzoo comp.windows.ms:11762 comp.sys.ibm.pc.misc:8866 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!rphroy!caen!uwm.edu!bionet!agate!stanford.edu!rutgers!mcnc!rti!bcw From: bcw@rti.rti.org (Bruce Wright) Newsgroups: comp.windows.ms,comp.sys.ibm.pc.misc Subject: Re: OS/2 2.0 is here! READ THIS, you'll be impressed Summary: Not such a bad example Message-ID: <1991Apr22.043548.13530@rti.rti.org> Date: 22 Apr 91 04:35:48 GMT References: <1991Apr21.135534.724@jarvis.csri.toronto.edu> <1991Apr21.175529.2386@jarvis.csri.toronto.edu> Organization: Research Triangle Institute, RTP, NC Lines: 93 In article <1991Apr21.175529.2386@jarvis.csri.toronto.edu>, wayne@csri.toronto.edu (Wayne Hayes) writes: > In article <1991Apr21.194928.8267@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: > >> And with > >>a decent, *efficient* scheduler. (Downloading at 9600bps on my 33MHz 386 > >>takes 30% of my processor time under Windows 3.0! It shouldn't take more > >>than 5%.) > > > >How do they do that? Magic?? What do they do with wait loops? > > Actually you're right. I chose a bad example. A terminal program > probably has lots of wait loops that would require near magic to > detect and eliminate. Don't be so hard on yourself - it isn't a bad example at all. Doug, you just don't know what you're talking about. Writing communications software is one of the things I do for a living; people pay me lots of money to get these things to talk to each other. Doug's claims struck me as just blowing so much smoke, so on a whim I fired up a 9600 baud download on the MicroVAX II class machine I was running on, and found it took just about 25% of the CPU. Now the MicroVAX II is nowhere near a 33MHz 386 - it's probably not even the equivalent of a 16MHz 386SX in terms of raw CPU power; it doesn't even have a memory cache. I'm not sure offhand what the proper figure ought to be (most of my comm software is written for VAX machines), but 30% of the CPU is way too high. Properly written communications software on a modern operating system doesn't _have_ any "wait loops" in the sense of the traditional DOS busy wait polling loop - it goes to sleep waiting for an event of some kind to happen (the details will depend on the communications application and the OS it's written for). DOS doesn't have this in its vocabulary; comm programs written for DOS often _do_ have some kind of polling loop for this reason, and if you were sufficiently perverse to run such a beast under OS/2 or some other modern OS you'd get just about what you deserve (though a reasonably intelligent schedular can often detect what's happening and reduce the comm program's priority). In order to really take advantage of the new OS you'd have to get a program that would support it - whether this is worth it is something that only the user can decide, but it's definitely technically _possible_ to write comm software that doesn't take such a big percentage of the CPU. > 2) You don't share a single DOS session and there's no requirement to > handle all disks requests sequentially. In other words, DOS has a > single threaded file system whereas HPFS is multi-threaded. This is > also the reason Windows *completely* dies during floppy access. OS/2 > does not have this problem. This is also a good point - you don't realize how much you could be losing because of single-threading unless you've used an OS that supports multi-threading I/O operations on different drives. In many cases even multi-threading a _single_ drive can be beneficial if you can overlap several types of operations (such as overlapping actual disk I/O with inspections of in-memory file structure cache information). > >>Not enough? How about a new file system (HPFS == High Performance File > >>System) > > > >In other words, a fatal flaw! (Unless, of course, it can be turned off.) > > First, yes, you can "turn it off" in that you may choose not to install > it in the first place, and OS/2 will use plain old FAT. But why in the > world would you want to? Well-behaved DOS apps can easily have all disk > accesses trapped and translated to the HPFS equivalent OS/2 calls without > the DOS app's knowledge. I don't understand why HPFS should be a fatal flaw - there has never been any statement that the FAT file system will be removed from OS/2 at any time in the near future; if anyone really needs it for compatibility then they can use it. But there is some really neat stuff in HPFS - it's a significantly better file structure, in features, performance, and reliability. And the vast majority of apps aren't going to be aware of whether they are on FAT or HPFS - only things like the Norton Utilities or the like; and the major ones in that category are going to become HPFS-aware over time. All of this glosses over the question of whether OS/2 will succeed in the _marketplace_; from everything I've heard about the new version it probably will succeed _technically_ but that's only a small part (some cynics would say not even a very relevant part) of what it takes to succeed in the marketplace. OS/2 has been hailed as the PC OS of the future so many times that it's become sort of like the boy that cried wolf - at this point it may be very difficult to convince the marketplace that the system has finally grown up. Its reputation is that it is overhyped, overpriced, oversized, undercapable, and incompatible; even if _all_ of these (real) problems are addressed, the perception will still remain in many people's minds. I'm not at _all_ sure I'd bet anything on it winning in the end, but not for reasons that have much to do with Doug's comments. Bruce C. Wright