From: rjc@hal.gnu.ai.mit.edu (Ray)
Subject: Re: 040 and 486 and nap42487 knows nothing about CPUs.
Organization: /etc/organization
Date: Mon, 13 Apr 1992 01:32:03 GMT

In article <1992Apr12.235751.26074@ux1.cso.uiuc.edu> nap42487@uxa.cso.uiuc.edu (Nishith A. Patel) writes:
>I'll tell you wy the benchmarks are accurate. One,you seem to know exactly
>what my FP benchmarks do. Why don't you send me a copy of the source code
>and we ca look at them and find out that they are not FP tests at all, just
>integer tests. The Microprocessor report just does not know the difference
>between integer and FP, and just randomly grouped some under integer
>(yes, that is integer, i-n-t-e-g-e-r) and some under FP. (F-P). The world
>is lucky we have you here as no one else can determine what tests do what,
>probably not even the people who made them.
>
>Those benchmarks were not published by IBM or something, they were from the
>microprocessor report trying to compare CPUs.

    Look, do you or do you not understand which factors influence
speed? Compilers make a hell of a difference, so does memory speed,
and system bus design. This is why these "benchmarks" are bogus. They
don't state which system they were run on, which compile used, and
the design of the system.

   The only way to compare systems with benchmarks is to compare
equal compilers/systems. However instruction set differences make
comparing equal compilers almost impossible, execpt perhaps if everyone
used GCC.  Right now, on the RS/6000 I am using, the AIX CC compiler
beats GCC2.1 by 30% speed wise. It's optmized for the PowerCHIPs.


  The only way to truly compare chips is by their instruction timings.
The benchmark method doesn't compare chips, it compares chips, compilers,
and system design.

>You posted some benchmarks using I/O. Gee, you don't think a workstation
>will do better at I/O than a clone, do you? After all, clone makers
>make sure they have the highest throghput and best graphics speed, disk 
>access, etc so they can rival workstations. Not quite. As Jerry pointed out,
>the Apollo has good compilers that are optimized for Dhrystone (This is a 
>common thing to do with compilers, optimize them for the Dhrystone benchmark).
>I can just as easily show you a 486 system beating an 040 on the Dhrystone
>benchmark (I won't post any, as I do not remember the exact numbers for any
>of them). Try a Dhrystone on an Amiga with 040 and a 486 using commonly used
>compilers for both (say, Borland C++ or MS C 7.0 vs SAS- Sorry to break
>your hearts, but BLAZEC doing infinte dhrystones is NOT available for the
>Amiga, as many sadly believe).

     GCC2 is a availible on the Amiga. It optimizes Motorola code better
than SAS.  Once again, you prove that what is being compared here
is compilers, not CPU's. Let's say Borland is twice as good at optmizing
Intel code as SAS is at Motorola code. Then comparing an Intel benchmark
compiled with Borland against a Motorola benchmark compiled with SAS
is not a fair comparison of the CPUs!

>And how about what I said earlier. About running tw similar apps on an
>Amiga and 486? Someone posted some stupid shit earlier about using 
>SUPERSUPERDUPERCAD on IBM vs. SUCKCAD on Amiga. That is not what I said.
>I said, use AutoCAD 386 and ANY cad program on the Amiga. Then try a series
>of tests. If anyone actually does this, don't post, unless you post every
>test you did and did every test not knowing how each system might do on it.
>I believe in fair benchmarks, impartially and taking account all of them.
>Thesystems should be using the CPU only, with similar levels of things
>like memory bottleneck (no 40 ns vs 120 ns). If the tests are true and
>comprehensive, not just a few selected ones where the 040 is particularly
>well suited, then benchmarks do give you a pretty good idea. Because
>all people use computers for anyway is to run programs. Nobody runs anything
>in theory, Jarkho).

   This is even worse. Comparising CAD programs on difference systems
depends on bus, video bottleneck, OS overhead, algorithms used in the
program, the compile, memory speed, and the bus!

  Let's just face the fact (my personal opinion) that the Intel
instruction set sucks, its kludgy, modal, limited in registers, not
orthogonal. Its a real bitch to program in assembly compared to Motorola.

  BTW, the 040 isn't supported well by current compilers. Most 040 code is
compiled by 68020 compilers, however, the 040 needs pipelining optimizations
like RISC chips, therefore the 040 benchmarks are even further skewed.

>Nish Patel  nap42487@uxa.cso.uiuc.edu
>A
>