From owner-sc22wg5@dkuug.dk Thu Oct 9 22:03:53 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.10/8.9.2) id h99K3rNY026951 for sc22wg5-domo; Thu, 9 Oct 2003 22:03:53 +0200 (CEST) (envelope-from owner-sc22wg5@dkuug.dk) X-Authentication-Warning: ptah.dkuug.dk: majordom set sender to owner-sc22wg5@dkuug.dk using -f Received: from mail1.cray.com (mail1.cray.com [136.162.0.111]) by dkuug.dk (8.12.10/8.9.2) with ESMTP id h99K3bEt026941 for ; Thu, 9 Oct 2003 22:03:47 +0200 (CEST) (envelope-from longb@cray.com) Received: from relayb.mw.cray.com (relayb.us.cray.com [192.168.252.110]) by mail1.cray.com (8.12.10/8.12.10/gw-1.2) with ESMTP id h99K3sGE018669; Thu, 9 Oct 2003 15:03:54 -0500 (CDT) Received: from saffron.us.cray.com (saffron.mw.cray.com [172.31.27.14]) by relayb.mw.cray.com (8.12.10/8.12.10/hub-1.3) with ESMTP id h99K3rpl027499; Thu, 9 Oct 2003 15:03:53 -0500 (CDT) Received: from cray.com (mh-dhcp-172-31-20-122 [172.31.20.122]) by saffron.us.cray.com (8.8.8/Cray-server-1.6-nhsmod011017) with ESMTP id PAA602292; Thu, 9 Oct 2003 15:03:53 -0500 (CDT) Message-ID: <3F85C126.3080900@cray.com> Date: Thu, 09 Oct 2003 15:12:22 -0500 From: Bill Long Reply-To: longb@cray.com Organization: Cray Inc. User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Van.Snyder@jpl.nasa.gov CC: sc22wg5@dkuug.dk Subject: Re: (SC22WG5.3023) Wishes for future revisions of Fortran References: <200310091850.h99Ioce2025706@dkuug.dk> In-Reply-To: <200310091850.h99Ioce2025706@dkuug.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Cray-VirusStatus: clean X-Spam-Score: 0 () Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Van.Snyder@jpl.nasa.gov wrote: >I've just spent 40 hours tracking down a bug that turned out to have >resulted from a typo introduced during manual inlining of a procedure >with four executable statements (other than the END statement). The >procedure is referenced in dozens of places in a code of 140,000 or so >lines. Inlining it makes a difference of a factor of eight in the run >time, which was 14 hours on each of 386 3 GHz Pentium Xeon processors > Clearly need a better computer. :) >before the inlining. The bug arose in a case where one of the arguments >is a product of three arrays, each of which has a vector subscript, each >subscript of which has a vector subscript, each of which is a section. >Something like A(A1(A2(I:J)))*B(B1(B2(I:J)))*C(C1(C2(I:J))). Naturally, > A mess like that is probably going to result in a temp whether the subroutine is inlined or not. Storing and reloading the temp would seem insignificant compared to the 6 gather operations and the 2 multiplies. I suspect the real issue is just the call overhead. Getting rid of that, of course, is a big benefit of inlining. Although it is a quality of implementation issue, I would assume the compiler you are using supports some form of inlining. That would seem a better way to go than doing it manually. >this reference is the one that makes the most difference in the run time. >The reference is within an inner loop. I DID try creating an array temp >outside the loop to reduce the stress on the memory allocator. This >provided an improvement, but not nearly as dramatic an improvement as >inlining did. > >Can we PLEASE PLEASE PLEASE have an INLINE attribute for subprograms in a >future revision of the Fortran standard -- preferably the next one after >2003? > Inlining is certainly useful. However, do we want to get the standard tied into file system details? The issue with inlining is that the code to be inlined is (almost always) in a file that is different from the one being compiled. Somehow you have to provide the path to the directory with the code and the name of the object file that has the subroutine to be inlined. Do we really want that type of information part of the language syntax? Suppose you move the object files. Do you then have to modify the source of the callers? I really think this sort of thing belongs on the command line and not part of the language syntax. > >Words something like > > The INLINE attribute of a subprogram indicates that a substantial > performance improvement would result if the subprogram were to be > materialized in place of references to it. The INLINE attribute does > not change the interpretation of the subprogram or a reference to it. A > subprogram with the INLINE attribute shall not have the RECURSIVE > attribute. An internal subprogram has the INLINE attribute if the > subprogram within which it is defined has the INLINE attribute. > >would be acceptable. The last restrictions could, of course, be >constraints. Inlining need not be a requirement put onto the processor. >Advice is good enough. I wouldn't object to additional restrictions. >E.g., it may be necessary to prohibit it to have a local variable with >the SAVE attribute, or to prohibit it to have an internal subprogram >instead of specifying that the INLINE attribute applies to any internal >subprograms as well. > >The "same interpretation" requirement means that the inlined procedure >does NOT access the environment where it is inlined except by way of the >actual arguments. > >I realize there may be technical difficulties in inlining a module >subprogram into a different program unit if the inlined subprogram >accesses private module variables by host association. It's probably > Actually, inlining module procedures is much easier. At least you know where the code is, since that infrastructure is already there in order for the USE statement to work. Of course, specifying where the module information is located is usually part of the command line. As is the case for inlining with most compilers. >also impossible to inline type-bound references to it -- at least ones >from polymorphic variables. But being able to put the advice into a >program's text means that when a processor eventually becomes able to do >the inlining, compiling the program gives an immediate boost in >performance. > >No, compiler heuristics and command line arguments are not adequate, >unless the standard standardizes them -- which I think would be more work >than standardizing an INLINE attribute, and a big mistake as well. >Depending on command-line arguments is a portability headache for the guy >who developes or maintains the make files. > >-- >Van Snyder | What fraction of Americans believe >Van.Snyder@jpl.nasa.gov | Wrestling is real and NASA is fake? >Any alleged opinions are my own and have not been approved or disapproved >by JPL, CalTech, NASA, Sean O'Keefe, George Bush, the Pope, or anybody else. > > > -- Bill Long longb@cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120