alan@pdn.UUCP (Alan Lovejoy) (09/19/87)
In article <257@etn-rad.UUCP> jru@etn-rad.UUCP (0000-John Unekis) writes: /In article <7042@steinmetz.steinmetz.UUCP> davidsen@crdos1.UUCP (bill davidsen) writes: />I will quote some figures from Byte magazine, July 1987 issue. I />personally do not doubt the Intel benchmarks at all. If they chose to />select benchmarks which show the best points of their product, can you />... />test 68010 68020 68020 80386 /> 7.8MHz 16MHz 12.5MHz 16MHz /> 1w/s 1w/s 0w/s 0.5w/s /> -- 881@8 881@12 287@16 /> />Fibonacci 264.0 71.6 70.2 3.1 time in sec />Float 230.0 4.2 2.9 5.4 />Sieve 64.7 14.9 12.8 6.0 />Sort 111.3 19.8 12.6 9.7 />Savage 1884.3 8.8 24.8 35.1 /> />Whetstones 574.0 2114.0 2702.0 3703.7 whetstones / sec /> /... /first off - those were dhrystones, not whetstones, one is an integer test, /the other is floating point. / / I notice that you conveniently forgot the worst / Intel column / 80286 / 8Mhz / 1w/s / ---- /Fib 950 /Float 116.36 /Seive 26.71 /Sort 46.53 /Savage 1103.0 / / FLAME ON!!!---- / /I thought that the results of these tests looked particularly bogus, /so I looked up the BYTE magazine article to see what was going on. /The most obvious discrepancy was in the fibonacci sequence routine, so /I typed in their code verbatim and ran it on two machines for comparison. / /On a Motorola 68020 with 68881 at 12 Mhz the test ran in 69.1 seconds /On an Intel 80386/80287 in full 32 bit mode at 16Mhz it ran in 60.3 seconds /(Both systems had 1w/s memory and ran UNIX V) /Even with a 25% clock speed advantage the Intel processor was only ~12% /faster. /The machine used in the Byte article must either have been a Gallium Arsenide, /100Mhz custom chip, or the authors are guilty of a gross clerical error. /Perhaps they forgot to read the minute portion of the time on their stop /watch. / /I would hate to impugn the reputation of a Magazine like BYTE by suggesting /that they would publish a test where the results were deliberatley falsified, /but it is true that the best way to make INTEL look better than Motorola /is to LIE. And here's more fuel for the fire: I have a Stride 440 (68000 @12MHz 1 wait state) that runs the Sieve in 11.40 seconds (100 iterations). This is faster than BYTE's time for the Mac II (68020 @16MHz, two wait states). (Yes, the Mac II has two wait states: one for the HMMU or the PMMU, one so that NuBus devices can access mother-board memory safely; besides, it would require 60ns static rams to run a 16MHz '020 with no wait states.) The Sieve code on my Stride was produced by an optimizing Modula-2 compiler, not C or assembly. Also, in BYTE's own preview of the Mac II in the April edition, they claimed 0.67 seconds for ten iterations (in other words, 6.7 seconds for 100 iterations)--almost twice as fast as the time they claim in their more recent benchmarks. What gives here? (I saw a Levco Prodigy (16 MHz 68020) equiped Mac Plus do 10 iterations of the sieve in 0.67 seconds in the fall of 1985 at Macworld Expo in SF). BYTE likes to do benchmarks using interpreted BASIC. Very well, let's look at some benchmarks using an interpreted language: Smalltalk. These figures are from the September 1987 ParcPlace Systems Newsletter: (Geometric Mean of the 15 standard ST-80 benchmarks) (Virtual Machine) (CPU) Implementation Machine Implementor Performance (higher is faster) PS/68020 Cadmus MSW/5 Georg Heeg, Inc 250 (2.5 x Dorado) PS/68020 Sun-3/260 ParcPlace Systems 206 PS/68020 Cadmus MSW/4 Georg Heeg, Inc 185 PS/68020 HP 9000/350-c ParcPlace Systems 151 PS/68020 Sun-3/60 ParcPlace Systems 142 PS/68020 Sun-3/160 ParcPlace Systems 116 PS/68020 Macintosh II ParcPlace Systems 102 Standard Dorado Xerox PARC/SCL 100 PS/68020 Sun-3/50 ParcPlace Systems 89 Tek4406 Tektronix 4406 Tektronix 82 PS/68020 Apollo DN 3000-clr ParcPlace Systems 75 PS/68020 Apollo DN 3000-b/w ParcPlace Systems 72 ST80 KV5 Fuji Xerox 1161 Fuji Xerox 47 PS/68010 Sun-2/50 ParcPlace Systems 41 ST80KV4.2 Fuji Xerox 1121 Fuji Xerox 41 ST80KV5(*) Funi Xerox 1161 Fuji Xerox 41 PS/68010 Cadmus 9230 Georg Heeg, Inc 40 PS/68010 Atari 4160 Georg Heeg, Inc 37 PS/68000 Macintosh SE ParcPlace Systems 33 Smalltalk/AT IBM PC/386AT Softsmarts 28 PS/68000 Macintosh Plus ParcPlace Systems 27 Smalltalk/AT IBM PC/AT Softsmarts 18 Now, which architecture is faster? --Alan "you just have to choose your benchmarks carefully" Lovejoy (a In t
jans@tekchips.TEK.COM (Jan Steinman) (09/21/87)
<<<I will quote some figures from Byte magazine, July 1987 issue. I personally do not doubt the Intel benchmarks at all....>>> <<<BYTE likes to do benchmarks using interpreted BASIC. Very well, let's look at some benchmarks using an interpreted language: Smalltalk... Now, which architecture is faster?>>> One problem with most benchmarks is that they are easily twisted to suit some purpose. The Smalltalk Benchmarks are now considered invalid because one implementation caches compiled code. This means that the first time a method is executed, it will run slower than a non-cached implementation, because it is doing extra stuff to store the native code. On subsequent executions of the same method, however, the cached method will run at native code speed. The Smalltalk Benchmarks are all tightly looped, causing cached implementations to show good results that are not necessarily reflected by user experience. :::::: Software Productivity Technologies --- Smalltalk Project :::::: :::::: Jan Steinman N7JDB Box 500, MS 50-470 (w)503/627-5881 :::::: :::::: jans@tekcrl.TEK.COM Beaverton, OR 97077 (h)503/657-7703 ::::::