Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!mit-eddie!ll-xn!ames!ubvax!weitek!mahar From: mahar@weitek.UUCP Newsgroups: comp.arch Subject: Re: Dhrystone 2.1 Keywords: integer benchmark Message-ID: <391@attila.weitek.UUCP> Date: 12 Jul 88 17:25:00 GMT References: <517@pcrat.UUCP> <2294@sugar.UUCP> Reply-To: mahar@attila.UUCP (Mike Mahar) Organization: WEITEK Corporation, Sunnyvale, CA Lines: 33 I've noticed that the way people use the Dhrystone benchmark is very different than the initial intent. It was supposed to be used to evaluate computer architectures. Instead, it is used to evaluate C compilers. In the RISC world, this makes a certain sense. Given the following rule of thumb. For a given RISC architecture, Vax780mips = .7 * Clock in Mhz A 10Mhz RISC is about 7 VAX780 mips. This is true for Mips Co., 88000, 29000, and Weitek XL8000. This doesn't seem to hold true for SPARC. That machine seems to be between 5 & 6 VAX780 mips. Given this the Dhrystone benchmark is used to evaluate compilers for the various RISC processors. A very good optimizing compiler will eliminate all the code in Dhrystone except the calls to times. This would give the result of a divide by zero exception since the two calls to times would take place in less than a 60th of a second. None of the compilers are doing that yet but they are making great strides is optimizing the code for Dhrystone. For example. The string copy can be done a word at a time if the strings are guaranteed to be word aligned. Since the string copys in Dhrystone are of constants to local arrays, the compiler can guarantee that the strings are aligned and even do the string copy in-line. There is a divide in every iteration that can be eliminated. Clever compilers can get rid of the divide. High speed string compares can be written that compare a word at a time. These three tricks alone can almost double the Dhrystone rating of a machine. Fast string copy and compare are usefull library routines but they don't account for 30% of a typical program's time. The divide optimization would be part of a general strength reduction and could be more useful but I don't know how much more usefull. Mike Mahar -- Mike Mahar UUCP: {turtlevax, cae780}!weitek!mahar