Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!mordor!lll-lcc!ames!oliveb!intelca!clif From: clif@intelca.UUCP Newsgroups: comp.arch,comp.sys.nsc.32k Subject: Re: Re: Re: the NS32532 Message-ID: <2578@intelca.UUCP> Date: Wed, 15-Apr-87 11:34:32 EST Article-I.D.: intelca.2578 Posted: Wed Apr 15 11:34:32 1987 Date-Received: Fri, 17-Apr-87 03:10:30 EST References: <4190@nsc.nsc.com> <951@moscom.UUCP> <2577@intelca.UUCP> <219@homxb.UUCP> Organization: Intel, Santa Clara, Ca. Lines: 75 Xref: utgpu comp.arch:882 comp.sys.nsc.32k:70 > In article <2577@intelca.UUCP>, clif@intelca.UUCP (Clif Purkiser) writes: > > While, I agree that using a global optimizing compiler is not exactly > > kosher for the dhrystone benchmark it sometimes neccessary. For > > instance: the GreenHills C compiler is a globally optimizing compiler > > which generates good Dhrystone numbers for many architectures including > > the 80386 and 68020. Unfortunately, I can not find a compiler > > switch to turn off the global optimizer. > > Is this true? I have many results using the GreenHills compiler which > are not marked as having a global optimizer turned on. Are you sure > there's no switch to turn it off? > > I've been watching these benchmark wars for awhile now, and frankly, I'm > a little upset that I put myself in the middle as referee. With all these > new chips and super hot compilers, I've lost confidence in the validity > of many of the results that have been sent to me. I used to get > results from Joe Engineer; now I'm getting them from Montague F. Salesman. > And with the way the optimizing technology is taking off, I expect to > see a Commodore 64 reporting 50,000 dhrystones by years end :-). > > Here's the plea: turn off the optimizer and send the results marked > no opt, turn on the optimizer and send the results w/ opt, where > indicates peephole, global, read-programmers-mind, or whatever. > If it can't be turned off, say so. Meanwhile, any advice on modifying > the Dhrystone for version 1.2 such that a global optimizer won't be > able to remove anything will be appreciated. > > And remember, folks, that a test of compiler A/machine A versus > compiler A/machine B is valid. Compiler A/machine A versus > compiler B/machine A is also valid. Compiler A/machine A versus > compiler B/machine B is probably invalid if seeking the truth > about machine A/B's relative power, but may be valid if your > goal is to put 147 users on the machine whose only use is to > run the benchmark. > > > Rick Richardson, PC Research, Inc: (201) 922-1134 ..!ihnp4!castor!pcrat!rick > when at AT&T-CPL: (201) 834-1378 ..!ihnp4!castor!polux!rer > > [I know those compiler writers...they LOVE to change things] On the GreenHills compiler there is little difference between -O -O2 , reg and noreg options. I believe that Green Hills C 386 compiler uses the same basic switches for all architectures, so I suspect that ALL results using GHS are global optimizing. I am looking forward to being told that I am incorrect about GHS . Rick, I understand that you are not thrilled about refereeing benchmark.war but look at the good side: The dhrystone benchmarks is better (i.e larger and closer to modeling an application) than most other benchmarks. It is standardized (not like the EDN benchmarks ) It seems to be accepted by most of the uP vendors AMD, Fairchild, Intel , Motorola and National and there exists a very large number of results which seem to be ordered properly (i.e CRAYs are faster than Commodore 64s) I think that work we have down on USnet has been helpful in providing information to engineers trying to understand the performance claims of computer vendors. The only true benchmark is your application, but the Dhrystone serves as an important data point. -- Clif Purkiser, Intel, Santa Clara, Ca. {pur-ee,hplabs,amd,scgvaxd,dual,idi,omsvax}!intelca!clif These views are my own property. However anyone who wants them can have them for a nominal fee.