# \`target\` attribute seemingly affecting performances **URL:** \ **Category:** GNU\ **Created:** [January 28, 2025, 10:27am UTC](https://fortran-lang.discourse.group/t/target-attribute-seemingly-affecting-performances/9137 "2025-01-28T10:27:20Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![mEm](https://avatars.discourse-cdn.com/v4/letter/m/90ced4/32.png) [@mEm](https://fortran-lang.discourse.group/u/mEm)\ **Post date:** [January 28, 2025, 10:27am UTC](https://fortran-lang.discourse.group/t/target-attribute-seemingly-affecting-performances/9137/1 "2025-01-28T10:27:20Z")
While working on the complete refactoring of a Modern Fortran code, I probably stumbled, very casually but fortunately, onto a very bizarre finding from my POV. So, previously withing a very computationally intense procedure, some local variables were declared with the `target` attribute, since they were pointed by some other `pointer` local variables. Now, in the refactoring, those pointer variables have gone. So far so good. Now, while cutting off all the unnecessary textual part, I noticed that that `target` attribute was not needed anymore (and also to shield against some unwanted forgotten things, so that if something still points at them, then I’d run into a compile time error), and boom, got more than 10% speedup by having removed the attribute. To then double check it was not something “casual” I recompiled an run several times again with/without the attribute, which confirmed the finding. The compiler with which I am seeing this is `GFortran 12.3.0` on `Ubuntu 22.04` OS. Now, the question: is this something to expect? I would like to test with some other compilers, but I won’t be able to test those in the short time. ---
**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\ **Post date:** [January 28, 2025, 11:56am UTC](https://fortran-lang.discourse.group/t/target-attribute-seemingly-affecting-performances/9137/2 "2025-01-28T11:56:20Z")
This is not surprising, as the `target` attribute basically tells the compiler that the variable is possibly aliased to another variable, thus preventing some optimizations or making them more difficult. ---
**Author:** ![themos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/themos/32/521_2.png) [@themos](https://fortran-lang.discourse.group/u/themos)\ **Post date:** [January 28, 2025, 1:03pm UTC](https://fortran-lang.discourse.group/t/target-attribute-seemingly-affecting-performances/9137/3 "2025-01-28T13:03:50Z")
Yes, you can expect that. My reasoning goes as follows: The TARGET attribute specifies that the array could be the target of an association. Implementers, guided by the Standard, have determined that the way such associations are kept track of is by having a memory address, index bounds for each dimension, and an address offset for each dimension telling you how much to add to the memory address for each index increment. That means you can’t place elements of the array in any faster resources, like SIMD registers, (without always updating the in-memory copy, every time you update). You can read about gfortran’s array descriptors [here](https://thinkingeek.com/2017/01/14/gfortran-array-descriptor/). You could implement a more complicated array descriptor, that kept track of how some elements are in some registers, but as far as I know, nobody has bothered, probably with good cause. ---
**Author:** ![themos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/themos/32/521_2.png) [@themos](https://fortran-lang.discourse.group/u/themos)\ **Post date:** [January 28, 2025, 1:17pm UTC](https://fortran-lang.discourse.group/t/target-attribute-seemingly-affecting-performances/9137/4 "2025-01-28T13:17:02Z")
It occurs to me that BLOCK could allow for a TARGET variable to lose that attribute for the duration of the BLOCK. The programmer would be responsible for ensuring that no associated variable is referenced for that duration, and in exchange the compiler would place the variable where it liked, restoring the original placement/association at the end of the BLOCK. An inlined copy-in/copy-out, if you like. ---
**Author:** ![everythingfunctional](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/everythingfunctional/32/176_2.png) [@everythingfunctional](https://fortran-lang.discourse.group/u/everythingfunctional)\ **Post date:** [January 28, 2025, 1:39pm UTC](https://fortran-lang.discourse.group/t/target-attribute-seemingly-affecting-performances/9137/5 "2025-01-28T13:39:33Z")
> [@themos](#): > > It occurs to me that BLOCK could allow for a TARGET variable to lose that attribute for the duration of the BLOCK. A procedure argument without the `target` or `pointer` attribute does this. ---
**Author:** ![tyranids](https://avatars.discourse-cdn.com/v4/letter/t/3e96dc/32.png) [@tyranids](https://fortran-lang.discourse.group/u/tyranids)\ **Post date:** [January 28, 2025, 4:44pm UTC](https://fortran-lang.discourse.group/t/target-attribute-seemingly-affecting-performances/9137/6 "2025-01-28T16:44:58Z")
> [@themos](#): > > That means you can’t place elements of the array in any faster resources, like SIMD registers, (without always updating the in-memory copy, every time you update). I haven’t looked at compiler explorer, but that’s insane. Seems like a massive downside to using Fortran pointers if anything with target attribute will never go in SIMD registers. ---
**Author:** ![hkvzjal](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/hkvzjal/32/3055_2.png) [@hkvzjal](https://fortran-lang.discourse.group/u/hkvzjal)\ **Post date:** [January 28, 2025, 4:59pm UTC](https://fortran-lang.discourse.group/t/target-attribute-seemingly-affecting-performances/9137/7 "2025-01-28T16:59:41Z")
If I read correctly @themos and @everythingfunctional replies, it just means that you should not mix in the same scope, pointer semantics and computational intensive tasks. So, mingle with pointers in “management” procedures, and use restricted scopes (blocks/subroutines/functions) which internally don’t have any pointer/target attribute to get the performance back. Is that it? ---
**Author:** ![themos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/themos/32/521_2.png) [@themos](https://fortran-lang.discourse.group/u/themos)\ **Post date:** [January 28, 2025, 5:42pm UTC](https://fortran-lang.discourse.group/t/target-attribute-seemingly-affecting-performances/9137/8 "2025-01-28T17:42:53Z")
Every association is an opportunity to lose performance. You are handing the compiler the job of doing the book-keeping, so you don’t run the risk of messing it up yourself. The language/compiler have knowledge of a few flavours of association and hopefully get the book-keeping correct. You could always do just as well or better yourself, at the price of a lot more source code, or dropping down closer to the metal. Indeed, the procedure boundary is the oldest way we have of fencing-in the effects of associations so that we only need to worry about maintaining them at the beginning and end. Original FORTRAN won the performance war by having no associations at all (by at least some reckoning). ---
**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\ **Post date:** [January 28, 2025, 6:04pm UTC](https://fortran-lang.discourse.group/t/target-attribute-seemingly-affecting-performances/9137/9 "2025-01-28T18:04:59Z")
> [@themos](#): > > Original FORTRAN won the performance war by having no associations at all (by at least some reckoning). Indeed. While C was penalized by the “everything is pointer” paradigm. That’s basically why the `restrict` keyword had been introduced in C99: it tells the compiler “there’s no aliasing to the memory locations that are referenced by this pointer, you can optimize aggressively”. ---
**Author:** ![mEm](https://avatars.discourse-cdn.com/v4/letter/m/90ced4/32.png) [@mEm](https://fortran-lang.discourse.group/u/mEm)\ **Post date:** [January 28, 2025, 6:17pm UTC](https://fortran-lang.discourse.group/t/target-attribute-seemingly-affecting-performances/9137/10 "2025-01-28T18:17:11Z")
Thanks @themos @PierU for the clarifications. I did not think about aliasing actually. The “weird” thing though was that the `target` variable was never used in a pointer association (only bare memory copies). I would have expected the compiler to “see” that, and make as the `target` attribute was not there. ---
**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\ **Post date:** [January 28, 2025, 7:01pm UTC](https://fortran-lang.discourse.group/t/target-attribute-seemingly-affecting-performances/9137/11 "2025-01-28T19:01:33Z")
@mEm can you create a minimal reproducible example (MRE) of the above behavior with `target`? Create the simplest benchmark that shows the slowdown by just adding `target` to a declaration and no other change. Then we can discuss a specific example, look at the generated assembly and reason about what is happening and see if there is a way to implement it better inside the compiler. Without an MRE we can only reason in abstract way, like @PierU and @themos did above, which I agree with. However it might very well be that for a particular example the compiler can actually speed it up. ---
**Author:** ![themos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/themos/32/521_2.png) [@themos](https://fortran-lang.discourse.group/u/themos)\ **Post date:** [January 28, 2025, 7:45pm UTC](https://fortran-lang.discourse.group/t/target-attribute-seemingly-affecting-performances/9137/12 "2025-01-28T19:45:45Z")
> [@mEm](#): > > the [local] `target` variable was never used in a pointer association It looks like the compiler decided not to spend compile-time on checking through the code for absence of associations. I, similarly, doubt that a rank-2 local allocatable is checked that all allocates are of the form ALLOCATE(x(N,1)) or ALLOCATE(x(1,N)) and simplified to rank-1 objects. ---
**Author:** ![mEm](https://avatars.discourse-cdn.com/v4/letter/m/90ced4/32.png) [@mEm](https://fortran-lang.discourse.group/u/mEm)\ **Post date:** [January 29, 2025, 8:24am UTC](https://fortran-lang.discourse.group/t/target-attribute-seemingly-affecting-performances/9137/13 "2025-01-29T08:24:51Z")
I will try to get one hopefully working without needing to go too much complex, and try to be as fast as I can. ---
**Author:** ![mEm](https://avatars.discourse-cdn.com/v4/letter/m/90ced4/32.png) [@mEm](https://fortran-lang.discourse.group/u/mEm)\ **Post date:** [January 29, 2025, 8:27am UTC](https://fortran-lang.discourse.group/t/target-attribute-seemingly-affecting-performances/9137/14 "2025-01-29T08:27:08Z")
> [@themos](#): > > I, similarly, doubt that a rank-2 local allocatable is checked that all allocates are of the form ALLOCATE(x(N,1)) or ALLOCATE(x(1,N)) and simplified to rank-1 objects. I don’t know if that’s also part of the issue or not, but in fact funnily enough, without even saying it, the local `target` variable had shape of the like `[1, N]`, since it was then used in a `matmul` operation. And the reasoning I assumed, maybe being wrong, was that “I can avoid needing to do a `reshape` at the time of the `matmul` when I can declare it with shape `[1, N]`, since it can be easily treated as a 1D array”. ---
**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\ **Post date:** [January 29, 2025, 9:22am UTC](https://fortran-lang.discourse.group/t/target-attribute-seemingly-affecting-performances/9137/15 "2025-01-29T09:22:14Z")
> [@themos](#): > > It occurs to me that BLOCK could allow for a TARGET variable to lose that attribute for the duration of the BLOCK. How? ---
**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\ **Post date:** [January 29, 2025, 9:24am UTC](https://fortran-lang.discourse.group/t/target-attribute-seemingly-affecting-performances/9137/16 "2025-01-29T09:24:27Z")
> [@certik](#): > > However it might very well be that for a particular example the compiler can actually speed it up. Maybe. But the right way to me is to not use the `target` attribute when it’s not needed. ---
**Author:** ![themos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/themos/32/521_2.png) [@themos](https://fortran-lang.discourse.group/u/themos)\ **Post date:** [January 29, 2025, 11:14am UTC](https://fortran-lang.discourse.group/t/target-attribute-seemingly-affecting-performances/9137/17 "2025-01-29T11:14:07Z")
> [@PierU](#): > > How? There would be new syntax, maybe SUSPEND(TARGET :: _object-name-list_), a variant of _other-specification-stmt_, asserting that all references to each named object are through that name only, for the duration of the BLOCK. ---
**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\ **Post date:** [January 29, 2025, 11:17am UTC](https://fortran-lang.discourse.group/t/target-attribute-seemingly-affecting-performances/9137/18 "2025-01-29T11:17:04Z")
> [@themos](#): > > There would be new syntax, OK, I thought that you were refering to an already existing feature. ---
**Author:** ![themos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/themos/32/521_2.png) [@themos](https://fortran-lang.discourse.group/u/themos)\ **Post date:** [January 29, 2025, 11:26am UTC](https://fortran-lang.discourse.group/t/target-attribute-seemingly-affecting-performances/9137/19 "2025-01-29T11:26:06Z")
> [@mEm](#): > > I can avoid needing to do a `reshape` at the time of the `matmul` Yes, you never want to do a reshape in a hot loop body. People used to do rank-shenanigans in F77 with sequence association and assumed-size arrays. Now we are encouraged to do it with rank-remapping/bounds-remapping of pointers, and possibly leave a bit of performance on the table. ---
**Author:** ![ricriv](https://avatars.discourse-cdn.com/v4/letter/r/f17d59/32.png) [@ricriv](https://fortran-lang.discourse.group/u/ricriv)\ **Post date:** [January 29, 2025, 12:33pm UTC](https://fortran-lang.discourse.group/t/target-attribute-seemingly-affecting-performances/9137/20 "2025-01-29T12:33:34Z")
Sometimes pointers are used to access a deeply nested variable. ```fortran subroutine sub(var) type(t1), target :: var real, pointer :: p p => var%a%b(2)%c%d ``` Should it be considered bad practice from a performance point of view? [Next page](https://fortran-lang.discourse.group/t/target-attribute-seemingly-affecting-performances/9137.md?page=2)