Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!ncar!csn!kessner!david From: david@kessner.denver.co.us (David Kessner) Newsgroups: comp.sys.ibm.pc.hardware Subject: Re: Difference between 386/33 & 486/25 not counting fp Message-ID: <1991Apr14.215120.12728@kessner.denver.co.us> Date: 14 Apr 91 21:51:20 GMT References: <1991Apr12.073828.20663@agate.berkeley.edu> <1991Apr12.093457.4147@kessner.denver.co.us> <1991Apr13.154941.1204@jwt.UUCP> Organization: Kessner, Inc. Lines: 82 In article <1991Apr13.154941.1204@jwt.UUCP> john@jwt.UUCP (John Temples) writes: >>Anyway. These figures would indicate that the 486 is twice as fast as the 386 >>for the same clock speed. > >No they don't. They indicate that the 486 can run the Dhrystone twice >as fast as the 386. You can't take a number like the Dhrystone and >bandy it about as the be-all end-all benchmark, like some folks do with >Norton SI. You need to look at a system's performance over a wide >range of benchmarks before you start saying CPU X is twice as fast as >CPU Y. Yes, and no... Dhrystones, like SI, work very well in comparing CPU's of the same type-- ie 386 vs 386, and 486 vs 486. We, however, are comparing 386 with 486. So, it is important to know just what Dhrystones does and does not measure. It is mostly testing integer and string opterations, with some function calling for thrills. It does not measure floating point or any I/O speed. Also, because dhrystone code tends to be larger than the 8K internal cache of the 486 its results will be affected by a secondary cache. While it is true that "the 486 can run Dhrystones twice as fast as the 386", I believe that it is a good indicator of the difference between the 386 and 486. The best approach is to run several 'benchmarks'-- but we lack that luxery. Until then, I will consider the 486 twice as fast as the 386 for integer operations at the same clock speed. >I'm sure some of you remember a certain compiler maker who included >special Dhrystone optimizations in their C compiler. Who's to say that >the 486 (either by design or by chance) doesn't run the instruction mix >that represents the Dhrystone more efficiently than it might run some >other instruction mix? The benchmarks were compiled with the standard AT&T comiler as well as the GNU compiler-- FOR BOTH MACHINES. Where they could, the same binaries were used. Thus, the effects of a 'better instruction mix' is negated because both machines benifit from them. While it is true that there were several compilers that could recognise the dhrystone test, and essentally optimize it out, the AT&T and GCC compilers do not do this. >If you're going to buy a computer on which you'll be running the >Dhrystone as your main application, by all means, get the system which >has the best Dhrystone benchmark. But if you plan on using your system >for anything else, you'll want to see how your other applications >perform on it. Again, I believe that the dhrystone benchmark is a good (but not perfect) indicator of how integer and string based programs will perform. I would love to measure the time GCC would take to compiler EMACS-- until then we must be content with Dhrystones. The point of the Dhrystone tests that those journals did, and why I posted their results was this: These dhrystone results were done by one group of people that have many machines at their disposal. Because of the close-nit nature of their group, it was very easy for them to test each machine under very controlled conditions-- ie, one user, no UUCP or TCP/IP, same compiler and compiler options (or same binary). These benchmark results were RELIABLE and CONSISTANT, not at all like the other Dhrystone results that have appeared on this thread. Other benchmarks posted here have done many no-no's that could be avoided. Running MS-DOS based benchmarks is the first no-no. Others are running under different compilers and different benchmark versions. The bottom line is: Is the 486 faster than the 386? My answer is YES. When running integer and string based programs, it's about twice as fast. For floating point, about three time as fast. For MS-DOS programs, about 30-50% faster... Even if my figures have a 30% "fudge factor", the net result is the same: the 486 is good for power hungry applications. >John W. Temples -- john@jwt.UUCP (uunet!jwt!john) -- David Kessner - david@kessner.denver.co.us | do { 1135 Fairfax, Denver CO 80220 (303) 377-1801 (p.m.) | . . . If you cant flame MS-DOS, who can you flame? | } while( jones);