Need 286 "C" benchmark

[Dave Trissel]

In article <583 at intelca.UUCP> cem at 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 <whatever> 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"