Path: utzoo!utgpu!watserv1!watmath!att!att!linac!uwm.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!ncifcrf!lhc!nih-csl!helix.nih.gov!wayne From: wayne@helix.nih.gov (Wayne Rasband) Newsgroups: comp.sys.mac.hardware Subject: Re: LC Prediction (Was: New Macintosh Strategy) Message-ID: <598@nih-csl.nih.gov> Date: 2 Nov 90 22:25:22 GMT References: <9037@ncar.ucar.edu> Sender: news@nih-csl.nih.gov Distribution: na Organization: NIH Lines: 50 In article <9037@ncar.ucar.edu> hpoppe@ncar.ucar.edu (Herb Poppe) writes: > Although the LC has a 68020 running at 16MHz (as does the Mac II), it is > configured with a 16-bit data path to memory instead of the 32-bit data > path of the Mac II. Since two bus cycles are required to read 32-bits > from memory on the LC (where only one bus cycle is required on the Mac II), > the LC is only half as fast as the Mac II, all other things being equal. The LC isn't as slow as you might expect. I run some benchmarks on it the other day, and, due to its built-in video, it actually out performed the Mac II on a few graphics intensive benchmarks. The 16-bit data path does make the LC somewhat slower for CPU intensive tasks, but notice how It runs small integer benchmarks, such as the Sieve, as fast as the Mac II. This is probably because the code fits entirely inside the 68020's tiny 256 byte instruction cash. It is clear from these results that you wouldn't want to do number crunching on the LC without adding a third party FPU. Radius Benchmark V1.0b6 SE LC Mac II Mac IIfx Float 44.7 10 0.5 .2 Trig 452 86 1 .3 Butterfly 149 29 7.6 1.6 Ripples 1095 238 27.4 9 Sieve 41.4 8.8 8.5 3.1 Moire 28 8.2 13.2 3.8 Circles 25.7 19 21 17.5 Arcs 15.8 9.8 10.9 8 Speedometer 2.5 SE LC Mac II Mac IIfx Whetstones 7.2 35.6 51.5 199 Dhrystones 916 2104 2982 11321 Sieve 34.2 7.9 7.9 2.3 Savage 395 70 47.3 11.8 CPU .99 3.23 3.39 12.4 Math .98 4.76 6.72 26.2 "Sharpen" filter in Image(pixels/sec) SE LC Mac II Mac IIfx NA 57K 60K 172K