hpoppe@ncar.ucar.edu (Herb Poppe) (11/02/90)
In article <2730569E.19505@orion.oac.uci.edu> ajauch@orion.oac.uci.edu (Alex Jauch) writes: > I have a Mac II (about the speed of a LC I presume) ... 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. When pre-announcement rumors about the LC intimated it would have a 68020, I was disappointed. Since this was to be a low cost machine, it would be unlikely that they would offer the machine with a PMMU. That has turned out to be the case. So, no virtual memory in System 7.0 for the LC. However, when the machine was announced with a 16-bit data path instead of a 32-bit data path, my disappointment evaporated. Why is that, you say? Prediction: The reason that the LC is not going into full scale production until January '91 is because the LC will not be built with a 68020! Instead, it will sport a Motorola 68025. As I recall from Motorola's announcement early last year, the 68025 is basically a 68030 with a 16-bit data bus. That is, it has on-chip PMMU. At the announcement, Motorola said that they and "a major computer manufacturer" would make a significant announcement in the summer ('90). To my knowledge, no such announcement was made. My guess is that the "major manufacturer" was to have been Apple with news of a 68025 LC, but the chip wasn't far enough along for the announcement to take place. Hence the delay in availability of the LC until January. Of course, its possible that the 68025 will never see the light of day, or that it will be an LCx that has this chip. This chip is the equivalent of the 80386SX, and like that chip, could play an important role in low-cost desktop and portable Macs. Herb Poppe hpoppe@ncar.ucar.edu NCAR (303) 497-1296 1850 Table Mesa Dr. Boulder, CO 80307-3000
wayne@helix.nih.gov (Wayne Rasband) (11/03/90)
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
planting@cs.pitt.edu (Professor Harry Plantinga) (11/07/90)
>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. 16-bit data path, yes; half the speed, not necessarily. If I remember correctly, a data access on a Mac II has two wait states. That means that a memory access takes 3 cycles. If memory access on a Mac LC has 2 wait states, it could be that the two transfers occur within 4 cycles. That would make the LC 75% the speed of the II. Notice that I am not saying that this is the case. I don't know anything about the Mac LC. I'm just pointing out that the "half as fast" comment need not be true. In fact, MacUser benchmarks make it much more than half as fast. ---------- Harry Plantinga planting@cs.pitt.edu
jfr@locus.com (Jon Rosen) (11/09/90)
In article <9087@pitt.UUCP> planting@cs.pitt.edu (Professor Harry Plantinga) 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. > >16-bit data path, yes; half the speed, not necessarily. > >If I remember correctly, a data access on a Mac II has two wait states. >That means that a memory access takes 3 cycles. If memory access on a Mac >LC has 2 wait states, it could be that the two transfers occur within 4 >cycles. That would make the LC 75% the speed of the II. > You have also overlooked the fact that the data path only effects memory operations... Many instruction mix analyses that I have seen indicate that only 25-35% of all instructions in a normal application load are memory instructions (hence the effectiveness of RISC architectures)... Most instructions are reg-to-reg arithmetic, bit twiddling, compares, branches and the like... Since the 68020 is pipelined (8 byte pipe I believe), its instruction queue will be filled most times to that the smaller data path will not have that much effect on instruction fetches (they will be overlapped with other operations)... My guess is that a 16-bit data path 020 would only see a 20-25% loss in speed vs a 32-bit data path 020 given equal clock rates and no wait states. If the above issue regarding wait states is also taken into account, the difference might only be 15% slower... Jon Rosen
gillies@m.cs.uiuc.edu (11/09/90)
I can't believe they saved more than $2 by crippling the LC with a 16-bit datapath. Does anyone know for sure if this was a money - saving move (if so, how much)? Why did they do this? Was it the marketing guys complaining about too good a price:performance ratio?