(j3.2006) Did we intend to prohibit this?

[Bill Long]

On Mar 13, 2017, at 11:15 PM, Van Snyder <van.snyder at jpl.nasa.gov> wrote:

> 
> My code spends 88% of its time in one module.  That module had numerous
> procedures, each having numerous local automatic variables, each sized
> according to the current problem.  It was spending 12% of its time in
> the storage allocator.  I moved those local automatic variables to the
> main procedure in the module, sized them according to the maximum
> problem size, and converted the other procedures into internal
> procedures that access those variables by host association, which
> reduced the time spent in the storage allocator from 12% to 3%.  This
> observation suggested to me that answers to questions about avoiding the
> storage allocator would be useful at least to me.


Automatic variables tend to get placed on the stack, in which case minimal ?storage allocator? time would be involved unless you have to expand the stack.  What ?storage allocator? are you measuring?   Have you tried running with a larger page size for the virtual memory system?  That can reduce the overhead of frequent stack expansions. 

When you convert the procedures to internal procedures they are much more likely to be inlined, especially if they are small.  That could have  bigger impact on performance than frequent expansion and contraction of the stack.  

Looking at compiler optimization messages and the generated code can be a lot more informative that a single profile number. Especially if you are lucky enough that 88% of the time is localized to a single module. 

Cheers,
Bill


Bill Long                                                                       longb at cray.com
Fortran Technical Support  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101