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 ------------------------------------------------------------------------------