Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!nigel.ee.udel.edu!mccalpin From: mccalpin@perelandra.cms.udel.edu (John D. McCalpin) Newsgroups: comp.arch Subject: Re: Compilers & SPECmarks... Message-ID: Date: 11 Apr 91 19:19:03 GMT References: <1991Apr11.143529.17969@odin.corp.sgi.com> Sender: usenet@ee.udel.edu Organization: College of Marine Studies, U. Del. Lines: 37 Nntp-Posting-Host: perelandra.cms.udel.edu In-reply-to: streich@sgi.com's message of 11 Apr 91 14:35:29 GMT >>>>> On 11 Apr 91 14:35:29 GMT, streich@sgi.com (Mark Streich) said: Mark> |> In article <1991Apr9.052607.12055@news.iastate.edu>, john@iastate.edu (Hascall John Paul) writes: Mark> |> Mark> |> Is it time to axe "matrix300" from the SPECsuite? This makes the Mark> |> second instance (others?) of SPECnum which can only be explained by Mark> |> a compiler significantly reducing the problem. Mark> Perhaps it is time to split the SPEC numbers into two pieces: Mark> 2. A number based on how many integer and floating point operations Mark> the program *actually* performs when being run. Instead of getting Mark> "credit" for the number of operations to be executed as defined by Mark> the source code, "credit" is given for the runtime frequency of ops Mark> in the executable. Note that this is not relevant to what is being done with the Matrix300 code. The aggressively optimized code is doing *exactly the same* operations as the source, but is doing them in a *significantly different* order. My understanding of the state of the art is that this is not really very generally do-able --- it works for matrix300 because Gaussian Elimination of dense matrices is very well understood. My guess is that the compiler would end up doing considerably less well on any other piece of code (for which the optimum answer is not necessarily known by the compiler writers in advance). There was a fellow at Argonne, Wayne Cowell (I think), who had some preprocessing tools which performed various loop unrolling and compression tricks to reduce memory accesses. An early version of these codes is available with TOOLPACK. I understand that a much improved version is available in the NAG distribution of toolpack, but I have not seen it. -- John D. McCalpin mccalpin@perelandra.cms.udel.edu Assistant Professor mccalpin@brahms.udel.edu College of Marine Studies, U. Del. J.MCCALPIN/OMNET