Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site watmum.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!harvard!think!mit-eddie!genrad!decvax!harpo!whuxlm!whuxl!houxm!mhuxt!mhuxr!ihnp4!cbosgd!clyde!watmath!watnot!watmum!cdshaw From: cdshaw@watmum.UUCP (Chris Shaw) Newsgroups: net.micro Subject: Re: Re: Re: Need 286 "C" benchmark Message-ID: <137@watmum.UUCP> Date: Wed, 29-May-85 15:26:36 EDT Article-I.D.: watmum.137 Posted: Wed May 29 15:26:36 1985 Date-Received: Thu, 6-Jun-85 20:31:54 EDT References: <426@oakhill.UUCP> <8745@microsoft.UUCP> Reply-To: cdshaw@watmum.UUCP (Chris Shaw) Organization: U of Waterloo, Ontario Lines: 33 Summary: Benchmark graphs, anyone? >..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. > >Rick Sellens Actually, not calling Rick a "dreadfully wrong guy" or anything, the problem lies in searching for ONE machine-producible number to tell the whole story. TWO machine producible numbers is all you need! :-) Or, more seriously, how about a program which does something useful, but which is variably sized in data usage. You could then run a series of tests using (say) the Seive of Eratosthenes algorithm with arrays in size ranging from a 512 integer array elements to the full (virtual) memory space of the machine. The increments could be reasonably small, say 512 for the first few, then 1024, then 4096. After you have this battery of results, draw a graph with memory size along the x-axis, running time along the Y axis. You could then SEE any ridiculous loss in performance by a large rise in the graph. For 8086, you would see a rising graph with an increase in slope at x=64K. For 68000, you would probably see just a curve with a continuous rise. As an added bonus, you should either divide each performance number by the big-O order of the problem, or take the derivative of the running time. Either way, this is a hell of a lot better than running your average program ONCE and calling that a "benchmark". Chris Shaw watmath!watmum!cdshaw or cdshaw@watmath University of Waterloo In doubt? Eat hot high-speed death -- the experts' choice in gastric vileness !