rob@prism.TMC.COM (11/24/89)
>>>Now, suppose you run in a Desqview window... You are >>>running the processor in the protected mode and it will run faster > >>You are mistaken; protected mode will slow the processor down, as it >>must do access checking. ... >Not so, says the latest issue of PC Magazine. According to PC, the new >optimizations in the 486 design mostly affect protected >mode operation. They found that the projected speedup factor of 2 or more >from a 386-33 to a 486-25 was not realized for DOS applications, where they >found only a speedup of roughly 10%. Some of the 486-based machine >manufacturers (such as ALR and HP) claim that the projected speedup becomes >reality when running in protected mode. PC Mag. did not test the machines >in protected mode themselves. I suspect PC was trying to rationalize the relatively small speedup they found. Their explanation was essentially, "The 486 is too powerful for DOS". This may be true, but it's misleading. Neither the 386 nor the 486 shows its true mettle running 16 bit code under DOS, but in PC's tests, they're both running under the same handicap. And saying that the 486 speeds up only protected mode is incorrect; the 486's faster instruction execution time applies to both real and protected mode. I think the 486 results come from several sources. First, the 486 only speeds up certain instructions. They're fairly common ones (like MOV and CALL), but this still means that different code will show different benefits. Second, the 486's speed is highly dependent on its cache's hit rate, which will also vary significantly between programs. Benchmarks, which tend to be fairly small programs, allow a very high hit rate, and often produce more impressive results than 'real-world' applications. Finally, it's possible to optimize code for the 486 (in real or protected mode) to gain speed. DOS applications obviously don't do this. This is reminiscent of the V20 vs 8088 issue, where the V20 offered a speedup that varied widely from program to program. Regarding protected mode, on a given CPU, a code sequence will normally run somewhat more slowly in protected mode, due to the overhead of protection checks and the more complex addressing logic. This overhead is typically around 10%, but varies depending on the code. The apparent speedup of the benchmark running under DesqView was, as a previous note said, probably a result of DesqView virtualizing the timer. >I suppose the best test would be to benchmark true 386 32bit applications on >both processors. Anyone with the hardware and software to do it? Some recent issues of MIPS magazine have done this.