Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!oakhill!davet
From: davet@oakhill.UUCP (David Trissel)
Newsgroups: comp.arch
Subject: Re: SPARC vs MC68040
Message-ID: <2943@oakhill.UUCP>
Date: 12 Feb 90 09:07:37 GMT
References: <8859@portia.Stanford.EDU> <5190@convex.convex.com> <1850@cbnewsi.ATT.COM> <2938@oakhill.UUCP> <3085@rtmvax.UUCP> <35825@mips.mips.COM>
Reply-To: davet@oakhill.UUCP (David Trissel)
Organization: Motorola Inc., Austin, Texas
Lines: 69

In article <35825@mips.mips.COM> mash@mips.COM (John Mashey) writes:

>>> is 23,148 KDhrys. The MC68040 runs that benchmark at twice the speed.

>A bunch of people at various companies are busily stuffing SPEC numbers into
>spreadsheets, plus published mips-ratings, and analyzing.  I'm also trying
>to calibrate i486 and 68040 numbers into this scheme.

What does this have to do with Dhrystone?

>	a) A bunch of Motorola people have been working hard along with the
>	rest of the SPECers to get better benchmarks, and have started getting
>	good compiler gains by analyzing real programs.
>	Talking about Dhrystone is a step backwards...

As has been discovered Dhrystones are an excellent way to find out how fast 
string operations go and to what extent C compilers incoporate them in-line. 
And the 1.1 version, since it is essentially a big NOP, can go a long way 
towards indicating how good a compiler is at removing dead code.

The Dhrystone benchmarks have known weaknesses. The SPEC benchmarks have their 
own. Many people are interested in Dhrystone so it gets talked about. If you
don't care for discussions on Dhrystone then simply ignore them.

>	b) In this newsgroup has been discussed many times why one has to
>	be careful with Dhrystone ratings.  Also, I quote from the author's
>	directions:
>"In any case, for serious performance evaluation, users are  advised  to
>ask  for  code listings and to check them carefully."

This true for ALL benchmarks. Do you think it only applies to Dhrystone?
Do you think it does not apply to the SPEC benchmarks? I know I wouldn't
be choosing a computer architecture without looking at code the compiler
produces.

>	EVERYBODY knows that inlining strcpy&strcmp can boost the number
>	strongly without giving anything like that boost on real programs.
>	SO POST THE CODE WHERE THE CRUCIAL STRCPY/STRCMP calls are made;
>	otherwise, the number is simply meaningless, because anybody can
>	boost the performance substantially on Dhrystone by an optimization
>	that has relatively little effect on real programs.

I fail to understand your tone here. By your own admission in a posting
you did to this newsgroup on March 15, 1989:

 "Now, according to the letter or the law of Herr Doktor Weicker's 
  Dhrystone 2.1 writeup, it's OK to in-line strcpy and strcmp.

and this is what the MC68040 compiler does. So just what is the problem? 
Here is one of the string copies (they all look similar) directly from the 
benchmark's .s file:

    lea.l   (12,%sp),%a5
    mov.l   %a5,%a1
    mov.l   &L%93,%a0
    mov.l   (%a0)+,(%a1)+
    mov.l   (%a0)+,(%a1)+
    mov.l   (%a0)+,(%a1)+
    mov.l   (%a0)+,(%a1)+
    mov.l   (%a0)+,(%a1)+
    mov.l   (%a0)+,(%a1)+
    mov.l   (%a0)+,(%a1)+
    mov.w   (%a0)+,(%a1)+
    mov.b   (%a0)+,(%a1)+

Now let's see you post the code that your MIPS compiler produces. Then tell
us what you find to be relevant about the two postings.

 -- Dave Trissel - Motorola, Austin