Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site cadovax.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!hao!hplabs!sdcrdcf!trwrb!trwrba!cadovax!keithd From: keithd@cadovax.UUCP (Keith Doyle) Newsgroups: net.arch,net.lang.c,net.micro,net.micro.pc,net.micro.68k Subject: Re: Re: Re: Need 286 "C" benchmark Message-ID: <649@cadovax.UUCP> Date: Mon, 3-Jun-85 20:52:52 EDT Article-I.D.: cadovax.649 Posted: Mon Jun 3 20:52:52 1985 Date-Received: Mon, 17-Jun-85 13:27:02 EDT References: <426@oakhill.UUCP> <8745@microsoft.UUCP> Organization: Contel Cado, Torrance, CA Lines: 59 Xref: linus net.arch:1147 net.lang.c:4845 net.micro:9428 net.micro.pc:3882 net.micro.68k:826 [..........] >In article <635@cadovax.UUCP> keithd@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"