Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site oakhill.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!umcp-cs!gymble!lll-crg!dual!mordor!ut-sally!oakhill!davet From: davet@oakhill.UUCP (Dave Trissel) Newsgroups: net.arch,net.lang.c,net.micro,net.micro.pc,net.micro.68k Subject: Re: Re: Need 286 "C" benchmark Message-ID: <433@oakhill.UUCP> Date: Fri, 24-May-85 10:38:47 EDT Article-I.D.: oakhill.433 Posted: Fri May 24 10:38:47 1985 Date-Received: Sun, 26-May-85 01:15:55 EDT References: <426@oakhill.UUCP> <8745@microsoft.UUCP> <583@intelca.UUCP> Reply-To: davet@oakhill.UUCP (Dave Trissel) Organization: Motorola Inc. Austin, Tx Lines: 69 Xref: watmath net.arch:1253 net.lang.c:5289 net.micro:10512 net.micro.pc:4042 net.micro.68k:801 In article <583@intelca.UUCP> cem@intelca.UUCP (Chuck McManis) writes: >> [quoting someone else...] >> I just love the contact sport of "combative benchmarking". I note how >> the source code for the Hofstader (sp?) benchmark just accidentally >> happens to declare its register variables from the least-used to the >> most used, the opposite of normal C convention. And by coincidence, >> there are three of those little hummers... and we're comparing a >> 68K with >3 regvars against a 286 with only 2! >> This means that the single most heavily used register variable will >> be in a reg on the 68K and on the frame for a 286. My my, what a >> terrible accident. When I posted the benchmark I was not aware of all that. But what's the complaint? Are you saying that its not fair to use registers since one chip only has 2 of them? In the real world programs would use a lot more than two registers. Why are you trying to hide architectural weaknesses? Benchmarks should be just the thing to point out such weaknesses. By your analogy no benchmark run between an Intel vs machine should have any statements such as the following: I = J; because the 808x et. al. do not have a memory to memory scalar move and would thus be artificially handicapped. That wouldn't be fair to Intel now, would it? >It is also by "accident" that of those three variables j, k, and max are >"assumed" to be 32 bits. ("Oh, did I leave that out?") And that the only >purpose of the histogram seems to be to try to allocate an array that has >250504 elements. I find this highly ironic coming from an Intel person. Intel's latest benchmark booklet comparing the 286 with the 68k just happens to be full of C programs which have ints. Intel doesn't bother telling anyone that the 68k versions all run with 32-bit integers while the 286 gets by with 16 bit integers. Deliberate deception - but we all know why. This quibbling is all very telling. If Intel advertizes that the 286 is not only far better than the several years old MC68000 but matches the speed of the new MC68020 one would think that these itty-bitty benchmarks certainly couldn't cause a problem. After all, every M68000 chip from day one easily chews them up. So what's the hangup here? If you have to go to LONGs then do it. But don't sit and gripe if you chip can't hack it. As for the large array, I have compiled the program on my Macintosh at home. No sweat. It runs easily on a 1 Meg Lisa (Mac XL.) Why is it such a big deal to run it on a 286 (which supposedly rivals the MC68020?) > >--Chuck >"I work with 'em and I like it." > >*** REPLACE THIS LINE WITH YOUR BENCHMARK *** Ok I will. Here's another dinky benchmark which I just compiled and ran on my Macintosh. Lets hear some 286 times for it (and no excuses please.) int a[50000]; main() { int i; for (i=0; i<50000; i++) a[i+1] = a[i]; } Dave Trissel {seismo,ihnp4}!ut-sally!oakhill!davet Motorola Semiconductor Inc. Austin, Texas "I work with 'em and mine works"