Performance with TARGET, ALLOCATABLE array .

[Andriy_R_]

Hi,

I have always thought that the TARGET statement is introduced as a tool to make sure that programmer does not point to a variable which should not be pointed to. I imagined that it only makes a difference during compile time. But...

Can it be that simply adding TARGET statement to ALLOCATABLE arrays declared in a module will generate any additional code hurting performance?

My colleagues run an experiment on our codebase. They took a module, where all ALLOCATABLE arrays for our solver are declared and inserted TARGET statement into each declaration. Everything was made “pointable” but no pointing was actually done. We currently do not use pointers at all.

! used to be
module A
   real(8), allocatable :: B(:)  
end module A

! changed to 
module A
   real(8), allocatable, target :: B(:)  
end module A

Then, they run a series of large experiments on actual data and found that code with TARGET attribute took 1-6% more time to finish simulations.

Hence, the question: does compiler generate any additional/different instructions for ALLOCATABLE arrays with TARGET attribute?

Thank you for any thoughts on this.

[Steven_L_Intel1 · Accepted solution]

Actually, TARGET tells the compiler that the variable in question may be aliased, so this disables certain optimizations. Don't use TARGET unless you really need it - almost always involving POINTER.

[E___Sebastian]

Hi,

in our application we were planning to have a container variable with ALLOCATABLE, TARGET attributes which holds a number of derived types. These derived types actually contain whole finite element problems that are being coupled in a simulation.

Now we stumbled upon the above comment and we wonder whether the compiler can still optimize what is being held in the container variable?

Thank you for any help,

Sebastian

[Steve_Lionel]

I think my comment above still applies in that TARGET removes some optimization opportunities. ALLOCATABLE is better than POINTER as the compiler knows that the data is contiguous. Your question is too vague, however, to say anything more definite.

[Roman1]

What would happen if a POINTER is passed to another subroutine, like in the example below?  Would the array optimization be done in performComputation?

subroutine performComputation( B )
   real,intent(inout):: B(:)

return
end subroutine performComputation

!-------------------------------------
   
subroutine setupProblem()
   real,allocatable,target:: A(:)
   real,pointer:: pA(:)
   integer m,n

   pA => A(m:n)

   call performComputation( pA )
return
end subroutine setupProblem

[Andriy_R_]

From my experience, you can not rely on compiler to optimize access and processing of your arrays.

Even when you do not do anything obviously difficult to optimize, compiler may decide that it does not have enough information to go full throttle optimizing it. I found that even supposedly innocent allocatable arrays passed in subroutine as real,intent(inout):: B(:), will not always be optimized on suspicion of not being contiguous.

I would advise everybody to explicitly provide full information to optimizer locally within each performance critical subroutines using !DIR$ and contiguous directives. Then, you do not have to alter your algorithm design just because some TARGET directive may or may not deteriorate your performance. SMH here.

Also, in my development I use Vectorization and Threading Advisor to go through each loop and understand how it was optimized. Or why some of the loops were not optimized.

Do your own due diligence. Do not rely on compiler.

[FortranFan]

E., Sebastian wrote:

.. in our application we were planning to have a container variable with ALLOCATABLE, TARGET attributes which holds a number of derived types. ..

Assuming the "container" in the above quote is a derived type itself and the "number of derived types." are components of such a derived type, note the Fortran standard does not allow components of derived types to have a TARGET attribute.