johnl@ima.UUCP (04/15/87)
In article <1622@bnrmtv.UUCP> connery@bnrmtv.UUCP (Glenn Connery) writes: >1) The 286 runs at least 50% FASTER in protected mode than in REAL mode. > If you think about it, this is obvious--REAL mode is a simulation. I am always astounded to see misinformation like this. I have in front of me an iAPX 286 Programmer's Reference Manual, published by Intel. In it are among other things the number of cycles each instruction takes. Any time you change the content of a segment register in protected mode, it has to look up its description in a table, which is slow. For example, an intersegment call takes 13 cycles in real mode, 26 in protected mode. An LDS instruction takes 7 cycles in real mode, 21 cycles in protected mode. For system calls, a real mode INT instruction takes 23 cycles while a protected mode "task gate" call takes 182 cycles (it saves and restores the entire system state.) In normal programs, most of the instructions do not modify a segment register unless you are manipulating large arrays, so the slowdown you'd see just from instruction execution would most likely only be a few percent. But it sure isn't faster. It is not inconceivable that you could get better performance from a protected mode operating system than you get from DOS. For example, it could load a 1MB program entirely into RAM rather than using the various overlay kludges you need to cram stuff into 640K. It could use intelligent disk scheduling and cacheing to reduce disk wait time. It could run several programs at once so you can get some work done at the same time you're dribbling data back and forth at 1200 baud. Indeed, the difference in the operating system is far more important than the slowdown that comes from running in protected mode. For the 386, pretty much the same discussion applies. The 386 executes instructions in roughly the same number of cycles as the 286, and real mode is again faster than protected mode. The 386 is faster in all modes, though, because its memory interface is wider, thus cutting down on the number of memory references needed to fetch instructions, and because 386 parts run at higher clock rates than 286 parts. The original issue was how fast OS/2 will be. I sure hope it's fast. But considering the performance problems that Microsoft has had with Windows, I'll be amazed if OS/2 is even as fast as DOS for comparable work. -- John R. Levine, Javelin Software Corp., Cambridge MA +1 617 494 1400 { ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl, Levine@YALE.something Where is Richard Nixon now that we need him?