Article View: comp.sys.intel
Article #207Re: 486 performance
From: Ian Ameline
Date: Sat, 08 Aug 1992 23:32
Date: Sat, 08 Aug 1992 23:32
102 lines
4155 bytes
4155 bytes
In article <12760@inews.intel.com>,
cpurkis@gomez.intel.com (Clif Purkiser) writes:
>
>> >In article <MeTM3Ry00VolQH2VFv@andrew.cmu.edu> cw1u+@andrew.cmu.edu (Chi-Tai (Frank) Wu) writes:
>> >
>> >On a 33MHz i486DX CPU system with 32MB of RAM and 256KB of cache:
>> >
>> >Dhrystone1.1 VAX MIPS: 27.6
>> >Dhrystone2.1 VAX MIPS: 26.3
>>
>> Amazing. When the 486/33 arrived, I remember the approx number being
>> 15 mips. Then Intel began insisting it was 21 mips. Now I see it's
>> evolved upwards again.
>>
>> This is encouraging. If I just wait, my machine will eventually hit
>> 100 mips and it won't cost me anything at all!
>>
>> -scott
>> ----
>> GrayMatter Software Co. 9 Courtland St. Holliston, MA 508 429-7867
>
>This is not all that surprising because Dhrystone and Spec are both
>a measure not just of CPU performance but of a compiler/system pair.
>The latest Mike Slater's Microprocessor Report has an article on
>benchmarking which claims that compiler performance increases by about
>1% per month. Internally some of our compiler guys claim a
>performance increase of 5%/quarter.
>
>The performance numbers we published are generally based on the best
>compilers we can find. Thus given that the i486 is two years old I'd
>expect a 25% increase in benchmark numbers.
>
>The ratio between the original Dhrystone MIPs number (21) and the
>new number (26.3) is 25%. Which means that the article is pretty
>accurate. I'll leave as excercise for the reader to figure out when
>a 33 MHz i486 will reach 100 MIPs. However, I think you'll need a new
>computer by than :-)
>
>Clif Purkiser
>Intel Software Technology Group
>
I'd be interested in knowing which compiler produced those dhrystone
numbers. Is it commercially available? Did it inline some of the
functions?
IMHO dhrystone is a very bogus benchmark. It is a great measurement
of how well a compiler yanks stupid or do-nothing code. Once you inline
everything, do the constant and copy propagation, dead and redundant
expression and store elimination, it's virtually all gone. I bet you'll
break that 100 "mip" barrier sooner than you think -- it just doesn't
mean anything any more.
Dhrystone is one of those programs compiler developers love to hate.
In order to get good numbers, you find yourself doing things which
will never help on real programs. For example, one part of dhrystone
goes like this:
Proc2(IntParIO)
OneToFifty *IntParIO;
{
OneToFifty IntLoc;
Enumeration EnumLoc;
IntLoc = *IntParIO + 10;
for (;;)
{
if (Char1Glob == 'A')
{
--IntLoc;
*IntParIO = IntLoc - IntGlob;
EnumLoc = Ident1;
}
if (EnumLoc == Ident1)
break;
}
}
Now you'll notice that EnumLoc is either undefined, or equal to Ident1.
Any compiler can figure that if it's undefined, it might as well
always be Ident1. The for loop gets tossed, the second if too, along
with the assignment to EnumLoc. IntLoc gets tossed, and replaced
with (*IntParIO+9), so the whole thing turns into:
Proc2(IntParIO)
OneToFifty *IntParIO;
{
if (Char1Glob == 'A')
*IntParIO += IntGlob+9;
}
Hardly typical of real programs, don't you think? Dhrystone has lots
of examples like this.
Specmarks, on the other hand, are excellent benchmarks -- they give
a much more accurate indication of the quality of the processor/compiler
pair.
Regards,
Ian Ameline.
IBM Canada Lab.
(The stuff above are entirely my own opinions)
Technical Details
Message-ID:
<19920808.163230.858@almaden.ibm.com>Path:
arc1-ca.pugleaf.net!sparky!uunet!vnet.ibm.comReferences:
<1992Aug4.205351.3073@unixland.natick.ma.us> <12760@inews.intel.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!vnet.ibm.com From: ameline@vnet.ibm.com (Ian Ameline) Message-ID: <19920808.163230.858@almaden.ibm.com> Date: Sat, 8 Aug 92 19:32:09 EDT Subject: Re: 486 performance Newsgroups: comp.sys.intel References: <1992Aug4.205351.3073@unixland.natick.ma.us> <12760@inews.intel.com> Organization: C-Set/2 Development, IBM Canada Lab. Disclaimer: This posting represents the poster's views, not those of IBM Lines: 102