Effect of intent(in/out) on performance ?

[FlyingHermes]

Hi,

As mentioned in the title, I was wondering what is exactly the effect on performance when using the intent(inout) attribute for procedure arguments.

Here is the context.
I have a big fortran code I have been using for a long time.
Very recently, I decided to make some cleaning-up in the source so I've compile the code using some restrictive options, namely:
[bash]FFLAGS= -O0 -pg -warn all -g -check bounds[/bash]Plenty of new and un-suspected compilation errors appeared. Some of them were related to an erroneous use of the intent attribute for procedure arguments.
Here is an example of the typical error:
[fortran]Subroutine Sub1( Var ) implicite none integer ,intent(in) :: Var call Sub2( Var ) ... End Subroutine Subroutine Sub2( Var ) implicite none integer ,intent(inout) :: Var Var = Var + ... End Subroutine[/fortran] This pseudo-code is wrong since:

1. in Sub1, Var is declared with the intent(in) attribute before being passed to Sub2
2. in Sub2 ,Var in declared with the intent(inout) procedure and it's value is changed

Obliviously, the Sub1 procedure must be modified by changing the Var attribute to intent(inpout).
However, since the Sub1 procedure don't need to return a value for Var, the copy-out operation is useless.
So, from a performance point of view, is it better not to specify the intent attribute in Sub1 ?

I'm asking because the original version of the code is much faster than the modified version.
Since lots of modifications have been done, I'm trying to identify which modification could have impact the code performance.

Thanks.

[Steven_L_Intel1 · Accepted solution]

I'd be astonished if your actual code looked as simple as what you showed here. However, as you declared Var to be intent(in) in Sub1, it would be a violation of the standard to pass it as an argument to Sub2 where the corresponding dummy argument is intent(inout). I assume that there is no explicit interface visible in your actual application, so normally the compiler can't check that. With -warn all, you get generated interface checking which complains about the conflict.

I don't think the compiler would do any argument copying here. You could try turning on "-check arg_temp_created" and run the program to see.

[FlyingHermes]

Thanks for this very quick answer !
Indeed, no argument copying is performed.

[jimdempseyatthecove]

>>Indeed, no argument copying is performed

But your program is in error - even though the compiler didn't catch it due to the lack of an interface block, the lack of an error message is not confirmation the the call is OK.

It is unfortunate that Fortran doesn't append argument signatures (as an option) that effectively requires a correct interface declaration. (the warn interface won't help with 3rd party libraries)

Jim Dempsey