Path: utzoo!attcan!uunet!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uxh.cso.uiuc.edu!beaucham From: beaucham@uxh.cso.uiuc.edu Newsgroups: comp.sys.ibm.pc Subject: Re: 486: Fantastic or Flop? Message-ID: <19500070@uxh.cso.uiuc.edu> Date: 4 Jun 90 20:16:00 GMT References: <1@ Lines: 35 Nf-ID: #R: Paul Giovacchini writes: < Did the machine tested have an AT bus? It must have. Because < the AT bus can not do the "burst mode" of the 486, the performance < increase that you will get, as I have read in about 3 different magazines < is "negligible". BUT if you have either a MCA or an EISA bus, which can < both handle the burst mode, the performance is astronomical. < This conclusion may be contradicted by PC Magazine's study (June 26, 1990, p. 113, "The Bus Wars") where for the ALR Power Casche 4 (with 25 MHz 486 cpu) configured as nearly-identical systems except for the bus, they show that the ISA bus is just as fast as MCA and EISA in 15 different benchmarks. While for most of the tests the results are just about the same, for disk controller operations reading small blocks, ISA and EISA rates were almost identical but surpringly exceeded the MCA rate by approximately 3 times. Also, for each bus, when the ALR 486 was compared to 386 machines of other manufacturers (IBM/MCA, Everex/ISA, Compaq/EISA), the 486 outperformed the 386 on the Dhrystone benchmark by substantial margins. Anyway, PC Magazine's conclusion is that ISA is as good as MCA or EISA for most real single-user DOS applications and is not worth the increased cost. Perhaps there is a benchmark which convincingly illustrates the power of the 486/EISA or 486/MCA over 486/ISA, but I haven't seen it. In terms of number-crunching benchmarks, I am seeing 26-28,000 Dhrystones and 1.0 Mflops for the 486-25 vs. 16-17,000 Dhrys and 0.5 Mflops for most 386-33 machines (under SCO Unix as per Personal Workstation, June, '90, p.63). Having the 387 internal to the 486 is a big plus, I think. In the future, it will probably force a reduction in the cost of floating point hardware. Jim Beauchamp j-beauchamp@uiuc.edu