Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!ll-xn!ames!ptsfa!hoptoad!farren From: farren@hoptoad.uucp (Mike Farren) Newsgroups: comp.sys.intel,comp.sys.ibm.pc Subject: Re: 80827 affects speed of 80286? (July Byte) Message-ID: <2362@hoptoad.uucp> Date: Sat, 4-Jul-87 14:30:53 EDT Article-I.D.: hoptoad.2362 Posted: Sat Jul 4 14:30:53 1987 Date-Received: Sat, 4-Jul-87 20:44:18 EDT References: <131@bby-bc.UUCP> Reply-To: farren@hoptoad.UUCP (Mike Farren) Organization: Nebula Consultants in San Francisco Lines: 35 Xref: mnetor comp.sys.intel:291 comp.sys.ibm.pc:5308 In article <131@bby-bc.UUCP> john@bby-bc.UUCP (john) writes: > >Compaq 386 16mhz 5850 2380 >386 Hummingboard 16mhz 6730 2777 >386 Hummingboard 20mhz 8650 3571 >Intel 386/20 6700 ---- > >The nonprotected mode was using Microsoft C in large model. >The protected mode used Metaware 386 High C in small (4 gigabyte segs) >model. > >8650 is pretty impressive. > >Anyone have a capsule description as to why protected mode is so >much faster? 1. The two compilers are different, and the dhrystones (and many other benchmarks) are as much a measure of compiler efficiency as they are a measure of processor efficiency. 2. MSC (4.0, at least) is not capable of taking advantage of '386 advanced characteristics, and, when compiling large model code, is know to produce very slow code. Not, perhaps, any slower than anyone else's large model 8086 and/or 80286 code, but certainly slower than small model. You don't indicate (or they don't) what compiler flags were used, either. Was it compiling 80286 code? 8086 code? Stack checks enabled? etc., etc. Show me some benchmarks created using the same compiler and the same compilation flags, and then maybe some reasonable theories can result. -- ---------------- "... if the church put in half the time on covetousness Mike Farren that it does on lust, this would be a better world ..." hoptoad!farren Garrison Keillor, "Lake Wobegon Days"