From owner-sc22wg5@dkuug.dk Thu Oct 9 22:47:20 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.10/8.9.2) id h99KlKZj027732 for sc22wg5-domo; Thu, 9 Oct 2003 22:47:20 +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 math.jpl.nasa.gov (math.jpl.nasa.gov [137.79.7.57]) by dkuug.dk (8.12.10/8.9.2) with ESMTP id h99Kl8Et027726 for ; Thu, 9 Oct 2003 22:47:15 +0200 (CEST) (envelope-from vsnyder@mls.jpl.nasa.gov) Received: from math.jpl.nasa.gov (localhost.localdomain [127.0.0.1]) by math.jpl.nasa.gov (8.12.8/8.12.8) with ESMTP id h99KlSAQ009616 for ; Thu, 9 Oct 2003 13:47:28 -0700 Received: from math.jpl.nasa.gov (vsnyder@localhost) by math.jpl.nasa.gov (8.12.8/8.12.8/Submit) with ESMTP id h99KlRrX009612 for ; Thu, 9 Oct 2003 13:47:27 -0700 Message-Id: <200310092047.h99KlRrX009612@math.jpl.nasa.gov> X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 To: sc22wg5@dkuug.dk Reply-to: Van.Snyder@jpl.nasa.gov Subject: Re: (SC22WG5.3024) Wishes for future revisions of Fortran In-Reply-To: Your message of "Thu, 09 Oct 2003 15:12:22 CDT." <200310092003.h99K3s1C026962@dkuug.dk> From: Van.Snyder@jpl.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Oct 2003 13:47:27 -0700 X-Spam-Score: 0.339 () NO_REAL_NAME Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Van.Snyder@jpl.nasa.gov wrote: > >.... The bug arose in a case where one of the arguments > >is a product of three arrays... > >Something like A(A1(A2(I:J)))*B(B1(B2(I:J)))*C(C1(C2(I:J))).... > > 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. When the dummy argument corresponding to the messy actual is referenced, it's in a loop instead of as an array expression. I.e., inside the routine I have do k = 1, size(arg) ... = ... arg(i) ... end do ! k So when it's inlined I have do k = i, j ... = ... A(A1(A2(k)))*B(B1(B2(k)))*C(C1(C2(k))) end do ! k so there's no array temp and no gather. The major part of the issue was not filling the actual argument's array temp, but creating and destroying the space for it in the innermost loop of my code. I tried creating a temp of largest size that would become necessary outside the innermost loop, and that helped somewhat, so filling the temp did have some cost. But the cost of figuring out what would be the maximum size ate up most of the benefit. > 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. It would certainly be better to have it done automatically than to do it manually. The problem is that some compilers do, and some don't. One of them, for example, can only inline external procedures, and then only if they're compiled in the same compiler invocation as the reference -- either by being in the same file, or by being in a file mentioned on the command line. My program is used by collaborators in Edinburgh, by colleagues in my department who use three different compilers, and eventually by at least one processing center that may use yet another compiler. Asking the makefile guy to find out how (if) to tell the several compilers to inline some procedures is something that will guarantee I'll be on his sh*t list for years to come. > 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. No. If you inline an external subprogram, I'd be perfectly happy if you either had to have it in the same file as the reference, or had to tell the processor where it is by some means not specified in the standard. I hadn't given much thought to inlining external subprograms, because my programs now consist almost exclusively of modules. > >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.... > > > > 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. That's good news, since my programs these days consist almost exclusively of modules. -- 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.