Need 286 "C" benchmark

[Keith Doyle]

[..........]
>In article <635 at cadovax.UUCP> keithd at cadovax.UUCP (Keith Doyle) writes:
>>we can write benchmarks that use 12 registers to make the Motorola look
>>good, and ones that use 2 to make the Intel look good.)
>
>Does this mean that if you have 16 registers and you only use 2 of them
>you pay a penalty for having 14 idle registers? This is about the only
>conclusion I can draw from your statement. How good is the 68K overall
>if it wins in benchmarks which use lots of registers and loses in benchmarks
>which don't use lots of registers?
>-- 
> Phil Ngai (408) 749-5720

I'm sorry, I should have included a :-) on that statement.  I was trying to
point out that you have to be careful with benchmarks, as no matter what
you have for a processor, it's not hard to customize your benchmarks to
say whatever you want.  Personally, I would be interested in Motorola vs
Intel benchmarks if we could all up front agree on a collection of things
to evaluate and look at them as a whole.  Even then, your intended use of
a processor will affect what you think of the benchmarks as a whole.

I will throw out a starting list of potential benchmarks that one might
use for a more thorough comparison, if there is any interest, let's add to
it and see if we can come up with a reasonable set that could actually be
useful in determining which is best for certain jobs.  Here is the list:

1. Test effect of code and data size for BOTH >64k and <64k.
   In addition, it might be useful to come up with some statistics on average
   code sizes in various environments, UNIX, PC, etc. perhaps so we can
   better decide how important this might be.

2. Test number crunching capabilities (multiply/divide etc) for BOTH 16 and
   32 bit quantities, probably exluding coprocessors (let's test them
   seperately-- later). 

3. Test higher level languages support including:
     1.  C    large and small model
     2.  Modula-2 and/or Pascal
     3.  Multiple stack oriented languages such as Forth, PostScript, Neon.
  and this probably includes both 16 and 32 bit tests.

4. Test performance effects of register set size.

5. Compare capabilities and performance of block-oriented instructions.


I'm sure there are others.  And, even if we come up with a better list, no
doubt not everyone will agree that it's a reasonable set.  Still, such tests
are more useful than the old:

       Well, suck on this:    for (i=0;i<500000;i=i+1)  a[i]=0

approach.

Keith Doyle
#  {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd
"There are 4 types of mendacity, lies, damned lies, statistics, and benchmarks"