Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!samsung!munnari.oz.au!uhccux!tholen From: tholen@uhccux.uhcc.Hawaii.Edu (David Tholen) Newsgroups: comp.lang.fortran Subject: Re: Array Notation Message-ID: <10818@uhccux.uhcc.Hawaii.Edu> Date: 3 Jan 91 22:34:18 GMT Distribution: comp.lang.fortran Organization: University of Hawaii Lines: 34 Presley Smith writes: > Array notation provides a simplified way to specify array operations > in many cases, but may, in fact, decrease the performance of the program. Microsoft FORTRAN version 5.0 also supports array notation, and on page 41 of the reference manual is the following note: In processing array expressions, the compiler may generate a less efficient sequence of machine instructions than it would if the arrays were processed in a conventional DO loop. If execution speed is critical, it may be more efficient to handle arrays element-by-element. So the problem isn't limited to the Cray compiler. What I'd like to know are the kind of situations in which array notation slows things down. Something as simple as C = A + B where all three are conforming arrays, can be done in two ways: with sequential memory accesses or with nonsequential memory accesses. The former should be faster than the latter, especially if nonsequential memory access results in a lot of paging to disk! With DO loop syntax, it's easy to handle the array subscripts in the wrong order, thereby causing nonsequential memory access, and I would hope that array syntax would eliminate that common programming error and execute as fast as the DO loop version with the subscripts specified in the right order. Maybe it's the more complex expressions that can be programmed more efficiently with DO loops, but can somebody give some examples? I've avoided using array notation simply because I don't know under what circumstances execution will be slowed, and given that it isn't standard yet, it represents a compiler "enhancement" that I don't want to use. You would think the compiler writers would provide a little more detail on when to use it and when NOT to use it, but so far...