Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!mips!apple!agate!web-1a.berkeley.edu!c60b-1eq From: c60b-1eq@web-1a.berkeley.edu (Noam Mendelson) Newsgroups: comp.sys.ibm.pc.hardware Subject: Re: Difference between 386/33 & 486/25 not counting fp Message-ID: <1991Apr9.085749.4568@agate.berkeley.edu> Date: 9 Apr 91 08:57:49 GMT References: <1991Apr7.232112.20682@agate.berkeley.edu> <1163@gistdev.gist.com> Sender: usenet@agate.berkeley.edu (USENET Administrator) Organization: University of California, Berkeley Lines: 52 In article <1163@gistdev.gist.com> flint@gistdev.gist.com (Flint Pellett) writes: >c60b-1eq@web-1e.berkeley.edu (Noam Mendelson) writes: >>In article dd2x+@andrew.cmu.edu (David Eugene Dwiggins) writes: >>>Is there a significant difference in speed between a cached 33 Mhz system >>>and a 486/25 system not counting floating point performance? >>>David >>Do you mean 33 MHz 386 vs. 25 MHz 486? If the 386 is cached, and you >>don't include the math coprocessor, it should be equal or faster than the >>486. Of course that depends on the size of the cache. >I sure hope people aren't basing buying decisions on the info presented so far >in this string. A lot of the numbers are wrong: a 33 MHz 386 with cache is not >the same as a 486. As someone who uses both a 386 AND a 486 machine daily, let >me try to set some stuff straight: >The 486 is a lot faster at everything: generally >2 times as fast, at the same >clock speed. That means a 25 MHz 486 runs about half again faster than a 33 >MHz 386. NOT AS FAR AS CPU PERFORMANCE IS CONCERNED. Given the same clock speed, the 486 runs roughly 50% faster. What you are talking about is a complete system's performance. This depends on memory, disks, etc., as well as the CPU. If you perform a CPU benchmark, please post the results. >But anyone who looks only at CPU speed in determining overall system >performance is foolish: the speed of your disks, the speed of your controller, >the bus speed, the speed of your memory (wait states), the speed of your video >adapter, it all matters. Unless you know what you are doing, even doubling one >of these factors may have no noticable improvement in speed for a specific >application: each different application will have it's own bottleneck. Agreed. But I was under the impression that this thread was concerning CPU's alone. >I have a 25 MHz 486 that uses 3 minutes to do a large C compile which takes 20 >minutes to do on an uncached 20 MHz 386: both have the same amount of memory. >If we pumped that 386 up to 33 MHz, it would be 1.65 times faster, and would >still take > 12 minutes. If, by some miracle, we could get 1.5 times the >performance through caching, it would still be taking 8 minutes. That 386 >doesn't have nearly as good a disk controller, although the disk speeds are >identical: my estimate is it would be 1.5 times faster with a better >controller, which would mean it would take 5 minutes compared to the 3 the 486 >uses. Does that sound equal to you? (Remember that software can make even >more difference- when I don't use Micro-Slow's compiler, I get the compile >done in under 2 minutes.) These kinds of generalizations can get you in trouble when comparing systems. Also, as I stated earlier, software speed does not necessarily imply CPU speed. +==========================================================================+ | Noam Mendelson ..!agate!ucbvax!web!c60b-1eq | "I haven't lost my mind, | | c60b-1eq@web.Berkeley.EDU | it's backed up on tape | | University of California at Berkeley | somewhere." |