Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

CLASS Dummy arguments

OP1
New Contributor II
459 Views

Assume I have a module variable declared as:

CLASS(MY_CLASS),ALLOCATABLE :: MY_VAR

Assume I have a procedure which takes MY_VAR as an argument. That procedure will not change the actual type of A or its allocation status (its content will be). Are there any performance benefits or issues for using any of the two approaches below?

SUBROUTINE S(MY_VAR)
CLASS(MY_CLASS) :: MY_VAR
...



SUBROUTINE S(MY_VAR)
CLASS(MY_CLASS),ALLOCATABLE :: MY_VAR
...

MY_VAR contains a huge amount of data and I want to make sure that no temporary copies are made for the call to S.

Edit: Just to clarify... S is not a type-bound procedure bound to MY_CLASS (and therefore MY_VAR is not a PASSed dummy argument).

0 Kudos
12 Replies
Steve_Lionel
Honored Contributor III
459 Views

My advice is to not declare the dummy as ALLOCATABLE unless you intend to allocate or deallocate it in the procedure. This won't change how the argument is passed.

0 Kudos
JohnNichols
Valued Contributor III
459 Views

Allocatable slows up code -- 

0 Kudos
FortranFan
Honored Contributor II
459 Views

Given how things are with most Fortran compiler implementations including Intel Fortran, you may want to first investigate for yourself in your actual application whether polymorphism can be eschewed and you can instead have the dummy argument with TYPE(x) where x is the expected type at run-time rather than CLASS(MY_CLASS).  It's highly likely you will gain performance with this approach.

0 Kudos
OP1
New Contributor II
459 Views

FortranFan wrote:

Given how things are with most Fortran compiler implementations including Intel Fortran, you may want to first investigate for yourself in your actual application whether polymorphism can be eschewed and you can instead have the dummy argument with TYPE(x) where x is the expected type at run-time rather than CLASS(MY_CLASS).  It's highly likely you will gain performance with this approach.

 

Thanks to all for the quick answers!

Regarding the quote above, I am aware of the cost of polymorphism in terms of overhead/execution speed; for the application at hand that cost is acceptable, but it would be a show-stopper if a temporary were created, for instance. I am glad to hear this is not a valid concern.

0 Kudos
Steve_Lionel
Honored Contributor III
459 Views

Nichols, John wrote:

Allocatable slows up code -- 

 

No, it doesn't. In this case, allocatable will have no effect whatsoever on performance.

0 Kudos
JohnNichols
Valued Contributor III
459 Views

Steve:

I respect your opinion, but in some recent work on the ODE solver, I moved from fixed to allocatable arrays and the time for analysis increased enough that I noticed the run time increase I print out for most programs.  There were no other changes. 

It may not be generally be true but for me it was. 

It was enough that I went back and took out the allocations to check and then decided the loss was not enough to worry about, so I put them back. 

Run times are really important to my work. 

John

0 Kudos
andrew_4619
Honored Contributor II
459 Views

Nichols, John wrote:

Steve:

I respect your opinion, but in some recent work on the ODE solver, I moved from fixed to allocatable arrays and the time for analysis increased enough that I noticed the run time increase I print out for most programs.  There were no other changes. 

It may not be generally be true but for me it was. 

It was enough that I went back and took out the allocations to check and then decided the loss was not enough to worry about, so I put them back. 

Run times are really important to my work. 

John

The process of actually Allocating will consume some time., if you alloc/dealloc a lot of times e.g. in a loop then that might use more time. Static arrays are not free of charge as the memory must be grabbed at at some point e,g, startup.

The fact that a thing is allocatable or not will not have much bearing on the speed  of things you do with it.  

 

0 Kudos
Steve_Lionel
Honored Contributor III
459 Views

Changing arrays from fixed to allocatable involves also changing to deferred-shape. This can have a performance penalty, though it depends a lot on what your program does with the array. My remark before was about declaring the dummy argument, a CLASS structure, to be allocatable or not; I maintain my view that, performance-wise, this doesn't matter.

Certainly if your program is making frequent allocations and deallocations, that takes time. But as data sizes get larger, allocatables start to become the only practical choice.

As a general rule, anything that defers a decision to run-time will impose a performance penalty. Whether that is significant depends on what you do with it. Compilers are pretty good at minimizing these penalties.

0 Kudos
jimdempseyatthecove
Honored Contributor III
459 Views

When a fixed array is used, (and) the shape and sizes are known at compile time, the compiler optimizations can eliminate looking at/into the array descriptor (and may eliminate the descriptor as well). Fixed arrays in these cases can indeed be faster to access, in particular, when the access is at fixed offsets. This is not as significant when an array is traversed in a loop as the offset and stride at start of loop can be extracted from the descriptor once (provided these values can be maintained within registers).

Jim Dempsey

0 Kudos
JohnNichols
Valued Contributor III
459 Views

Thanks for the expert comments,  I am not an expert on the use or otherwise of alloc against fixed.  mecej4 taught me all I needed to know with his great help with the MAGNI code and I still copy that code style, the issue came up as I was moving from fixed arrays to alloc arrays in moving in all of the methods I learnt for some ODE code.  I put in a timer and it showed the alloc was slower, not much but enough that I noticed it and thought it was odd and I remembered it. . 

I am certainly not going back, but in Fortran there is no certainty only Fortran and a lot of different computers.  

I remember once mecej4 said with the Magni code it would be a lot faster in Fortran than C#. I was sure he was wrong, so I spent an interesting weekend translating one to the other -- it is really not hard to go from C# code to Fortran for stuff that is really just math.  mecej4 was of course correct. 

It is all just fun and this is a safe place to express opinions, mostly. 

John

0 Kudos
jimdempseyatthecove
Honored Contributor III
459 Views

John,

If multi-dimensional array performance is a concern of yours, take a look at Peel the Onion (Optimization Techniques) on IDZ.

Jim Dempsey

0 Kudos
JohnNichols
Valued Contributor III
459 Views

Jim:

Thanks for the note.  It is not a concern, it was merely an observation in changing some code from Fortran 77 to modules, as learnt from mecej4, I am aware of timing, a bit critical on our data collection systems that follow a fixed cycle. 

It was just an observational comment on the duration.  I store these things up for class comments, instead of taking roll you only mention a fact once in the class and then put it on the next examination.  Makes it easy to find the A's. 

A classic one is "What is the length of a cigarette?" Answer legally == 1240 feet. 

John

 

0 Kudos
Reply