ASSOCIATE vs Setting Local Variables Which Is Best?

[ScottBoyce]

Hi All,

Just wanted to get peoples opinions to using the ASSOCIATE command compared to setting a local variable within a Fortran Subroutine.

Bellow would be an example code where I either use associate to use the shorter symbols A and B

and the other option of just having a local variable (say double precision) set to the values stored and then use them.

  ! 
  ASSOCIATE ( A=>TYP%SUBTYP(I)%SUBTYP(J)%PROP1, B=>TYP%SUBTYP(I)%SUBTYP(J)%PROP2 )
         !
         !Do stuff with A and B
         !
  END ASSOCIATE
  !
  ! OR
  A = TYP%SUBTYP(I)%SUBTYP(J)%PROP1
  B = TYP%SUBTYP(I)%SUBTYP(J)%PROP2
  !
  !Do stuff with A and B
  !

The main question is which would would be more beneficial to use, at what point does it become too many variables to reassign values (say if I had variables A-Z that were set). It seems like there would be a hit for copying the memory over to the local variables, but I am unsure how much of a speed hit there would be with initiating an ASSOCIATE local environment.

Thanks for your inputs!

[Steve_Lionel]

ASSOCIATE is just for visual clarity - it shouldn't have any noticeable effect on performance. You'll have to decide for yourself whether use of ASSOCIATE is reasonable.

[Andrew_Smith]

I believe that the associate should be quicker than copying for anything bigger than a scalar integer or scalar real variable, ie. an array larger of either than one element. You did not show a declaration for A or B so dont know for your example.

Steve, is my belief correct?

[Arjen_Markus]

I would expect ASSOCIATE to be syntactical sugar rather than a run-time construct. That is: it guides the compiler to transform the code instead of introducing new variables that act as a sort of pointers.

[Andrew_Smith]

Is it possible that optimisation will overcome speed issues and end up with similar run-times for both?

[jimdempseyatthecove]

Compiler optimizations typically perform common sub-expression substitution. IOW it may effectively perform the local variable scheme (as well as for associate form). Use of your own local variables can extend the scope of the life of the local copies. Local variables are not suitable for variables that are updated whereas associate can be used for both read and write.

Jim Dempsey

[Steve_Lionel]

Faster than copying? Yes. You can think of ASSOCIATE as, in a vague way, like EQUIVALENCE. It creates a new variable that represents some part of a variable or variable-part. You can get into performance issues if the selector is noncontiguous, but otherwise it is in most cases, as Arjen suggests, "syntactic sugar".

[mecej4]

I do not know if many current users of Fortran have used Pascal, but to me ASSOCIATE appears quite similar to Pascal's WITH; see http://lazarus-ccr.sourceforge.net/fpcdoc/ref/refsu45.html .

[Steve_Lionel]

Yes, it is similar.

[ScottBoyce]

Thanks, that is what I was thinking. I just have a lot of local double precision variables that are set within a loop at runtime and I am transitioning them to ASSOCIATE blocks instead to reduce the amount of locals in the subroutine. I just was worried there would be a hit on the runtime (to me it would seem like ASSOCIATE would be faster since its not copying over a memory location vs just setting some form for of pointer).

[jimdempseyatthecove]

Bare in mind that the target of an ASSOCIATE is not the same as a temporary. IOW you modify the associate variable - you also modify the associated variable.

Note, you can also use BLOCK/END BLOCK where immediately following BLOCK you can declare local variables (with names that can conflict with names used in other blocks as well as within an outer scope.

Jim Dempsey

[mecej4]

This is an implementation detail, but a Fortran compiler would regard the associate name and the associated name as two names for one and the same variable, as in EQUIVALENCEd variables. No temporary is needed.

Take the subroutine 

subroutine sub(a,b)
implicit none
integer :: a,b
!
b=2*a
associate(la=>a, lb=>b)
   lb=2*la
end associate
return
end subroutine

Compile this to assembly, with and without optimization. You will find two identical store instructions to b and lb with /Od. If you allow optimization, all you see is single store instruction to the single stack location that can be accessed by the names b and lb.

[ScottBoyce]

That really good to know that the behavior is different under optimization. I noticed that it created a shadow variable in the debugger, which is what prompted this discussion.