Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!zodiac!joyce!sri-unix!garth!walter
From: walter@garth.UUCP (Walter Bays)
Newsgroups: comp.arch
Subject: Re: Dhrystone 2.1
Message-ID: <973@garth.UUCP>
Date: 15 Jul 88 17:57:39 GMT
References: <517@pcrat.UUCP> <2294@sugar.UUCP> <391@attila.weitek.UUCP> <4936@husc6.harvard.edu>
Reply-To: walter@garth.UUCP (Walter Bays)
Organization: INTERGRAPH (APD) -- Palo Alto, CA
Lines: 50


    In article 4936 reiter@harvard.UUCP (Ehud Reiter) writes:
    ...the main benefit of Dhrystone and other benchmarks is not to
    predict performance (that's impossible, since no single figure of
    merit can predict the performance of widely differing application
    programs), but rather to help architecture designers design good
    computers, and compiler writers design good compilers, by giving
    them some real code which is at least slightly representative to
    play with.

That's true, though for these purposes I also like to look at real
applications and at customer-written benchmarks, which tend to be more
representative of real applications.  The great advantages of Dhrystone
are that it's easy to get, simple to run, and comparative figures are
readily available for many machines and compilers.  Richardson has
done a real public service in making it easy for different people to
run exactly the same code, and in making users more cognizent of
performance (resulting in demands for more performance, resulting in
more performance)

The danger of Dhrystone is when people start to view it as a kind of
"miles- per-gallon" single figure of merit.  Weicker's and Richardson's
warn against this in their advice on the use of the Dhrystone benchmark
That advice is very good.

    If the optimizations required for good Dhrystone performance
    include optimizations that are not relevant to real application
    programs, who cares - it doesn't do any harm to include rarely-used
    optimizations in a compiler.

I agree: a compiler should have the largest possible battery of
optimizations to choose from.  But judging from postings in
comp.lang.c, there are many users who would disagree.  Optimizations
have a cost in compilation time, even when not applied.  An applied
optimization may have no benefit on a particular application, yet have
a cost in memory size (i.e., excessive inlining).  Worst would be if an
"optimization" helped Dhrystones but hurt many application programs.
There are many optimizations that help some programs but hurt others,
and the compiler cannot always tell the difference.

To the extent that Dhrystones is used as a miles-per-gallon figure, the
temptation exists for compiler writers (computer architects?) to design
for Dhrystones at the expense of real applications, or to spend
precious resources speeding up Dhrystones that could have been used to
benefit ordinary programs.
-- 
------------------------------------------------------------------------------
My opinions are my own.  Objects in mirror are closer than they appear.
E-Mail route: ...!pyramid!garth!walter		(415) 852-2384
USPS: Intergraph APD, 2400 Geng Road, Palo Alto, California 94303
------------------------------------------------------------------------------