john@bby-bc.UUCP (john) (07/04/87)
In the July issue of Byte they benchmark the 68020 and 80386 using (among others) the dhrystone benchmark. They also give figures for the 80286 as a comparison. The figure for an 80286 with an 80287 is 13% faster than a 80286 alone but as I recall the Dhrystone benchmark doesn't do any floating point so this would indicate that the 80287 somehow speeds up the 80286 non float instructions somehow - is that really the case or are the results bogus? The actual numbers given are: IBM PC-AT (8mhz) 1567.9 IBM PC-AT (8mhz)+80287 1748.9 Also elsewhere in the issue (the BIX stuff) someone claims the following results for the 386 (Dhrystones again): protected mode nonprotected 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? john
farren@hoptoad.uucp (Mike Farren) (07/04/87)
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"
john@bby-bc.UUCP (john) (07/05/87)
> > 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. Sorry, they didn't give that information. I might rephrase my question to be: does the 386 slow down when it is emulating the 286? You would think that with 32 bit memory the 286 mode would get some benefit, e.g. faster instruction access (1 read to get 4 bytes of instruction compared to 2 on a real 286). Or in other words does SHL ax,1 take longer in 16 bit mode than 32 bit mode? john