Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site watdcsu.UUCP
Path: utzoo!watmath!watnot!watdcsu!rsellens
From: rsellens@watdcsu.UUCP (Rick Sellens - Mech. Eng.)
Newsgroups: net.arch,net.lang.c,net.micro,net.micro.pc,net.micro.68k
Subject: Re: Re: Re: Need 286 "C" benchmark
Message-ID: <1429@watdcsu.UUCP>
Date: Wed, 29-May-85 10:36:56 EDT
Article-I.D.: watdcsu.1429
Posted: Wed May 29 10:36:56 1985
Date-Received: Thu, 30-May-85 02:44:56 EDT
References: <426@oakhill.UUCP> <8745@microsoft.UUCP> <583@intelca.UUCP> <433@oakhill.UUCP> <588@intelca.UUCP> <5704@Shasta.ARPA>
Reply-To: rsellens@watdcsu.UUCP (Rick Sellens - Mech. Eng.)
Organization: U of Waterloo, Ontario
Lines: 23
Xref: watmath net.arch:1266 net.lang.c:5309 net.micro:10545 net.micro.pc:4064 net.micro.68k:821
Summary: 


I think the subject that this discussion is running under says it all.
If you go looking for a benchmark "for the 286" you will select a small
memory program if you are an Intel fan, and a large memory program if
you are a Motorola fan. The flaw lies in trying to select a benchmark
for a machine, rather than an application.

To *reasonably* benchmark anything you need an idea of what the application
will be. A benchmark can then be written to test the particular features
that are important in the expected use. A machine that screams at integer
operations in a small memory space may or may not be any good at doing
floating point work in a large memory space.

Please try to test individual capabilities when you benchmark, and then
report the results as representative of *only* those capabilities. That
way maybe we can start to intelligently answer the questions about what
machines do what things faster than others.


Rick Sellens
UUCP:  watmath!watdcsu!rsellens
CSNET: rsellens%watdcsu@waterloo.csnet
ARPA:  rsellens%watdcsu%waterloo.csnet@csnet-relay.arpa