Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!lll-winken!sun-barr!newstop!texsun!csccat!egsner!convex!metzger From: metzger@convex.com (Robert Metzger) Newsgroups: comp.benchmarks Subject: Re: Price/Performance figures for Number-Crunching Keywords: compilers, pattern matching Message-ID: <1991Mar21.185023.9183@convex.com> Date: 21 Mar 91 18:50:23 GMT References: <1991Mar20.104926@IASTATE.EDU> <1991Mar21.000302.10103@convex.com> Sender: news@convex.com (news access account) Organization: Convex Computer Corporation, Richardson, Tx. Lines: 50 Nntp-Posting-Host: bach.convex.com In article <1991Mar21.000302.10103@convex.com> patrick@convex.COM (Patrick F. McGehearty) writes: >> >>Carter> Another problem with MFLOPS and LINPACK is "benchmark rot". >>Carter> The LINPACK benchmark has become so important that compilers >>Carter> now have "LINPACK recognizers" that drop in super-optimized >>Carter> code whenever they see a structure that looks like the LINPACK >>Carter> kernel. >> >Mccalpin>Documentation? Or is this another "urban myth"? >> > >On the compiler development side (where I sit), LINPACK certainly has >been a "compiler smoother". Several of our current optimizations were >driven by LINPACK. They are not specific to LINPACK, since they will >work for most dense vector*vector or matrix*vector code, but they >certainly are important to getting the LINPACK results we get. Is this >the sort of "LINPACK recognizer" that Carter was refering too? If so, >I am concerned about the apparent distain for "pattern recognizers". >Pattern recognition is a critical tool in the optimizing compiler's tool bag. >There are large numbers of such "pattern recognizers" in any good optimizing >compiler, and a good compiler development group is continually trying >to identify new ones that have at least moderate degrees of utility. Let's distinguish between "surface" and "semantic" pattern recognition. Surface PR does things like: Finds the lexemes 'REAL*4 FUNCTION SAXPY', junks the lexemes until it sees 'END', and either directly inserts highly optimized assembly code, or hacks the link line to include a special library of highly optimized code. In other words, it doesn't do any compilation at all. Anyone who cares about accurate results from something like LINPACK should replace all the procedure names with JOE, FRED, etc. before compiling. Semantic PR analyzes the control flow, data flow, and symbol definitions of a procedure to determine its purpose, if the procedure was not amenable to other optimization methods. It should recognize a pattern regardless of: 1) the spelling of the lexemes 2) whether the loops were coded with DO, DO WHILE, or IF-GOTO 3) whether the results of individual arithmetic operators are assigned to temporary variables or used as a part of larger expression etc., etc. CONVEX compilers do perform semantic pattern matching on a handful of general patterns, that do not lend themselves to standard vectorization techniques, and which occur frequently in user applications. -- Robert Metzger CONVEX Computer Corp. Richardson, Texas Generic Disclaimer: I write software, not CONVEX Corporate Policies. "The only legitimate function of government is to protect its citizens from harm or property loss by violence, stealth, or fraud. All else is tyranny."