CODEWITHSUNDEEP
performancepointersfortranargument-passing
apetros85
apetros85

Reputation: 461

Huge slowdown when packing arguments into derived type with pointers in Fortran

I have a complicated structure which a driver subroutine calls several user libraries. Many arguments need to be passed. To avoid the possibility of making a mistake, I decided to pack the arguments in a derived type structure and use pointers. I've noticed that this packing makes a big slow-down. I've made a working example with the two alternatives. https://dl.dropboxusercontent.com/u/258337/stackoverflow/working_example.f90 uses the derived type while the https://dl.dropboxusercontent.com/u/258337/stackoverflow/working_example_alt.f90 passes the arguments directly. The real system is much more complicated than this but this is representative of what happens.

I compile both with -O2 and use time to measure their performance:

$ ifort -O2 -o test working_example_alt.f90 && time ./test 
real    0m0.769s
user    0m0.768s
sys 0m0.000s
$ ifort -O2 -o test working_example.f90 && time ./test 
real    0m1.441s
user    0m1.444s
sys 0m0.000s

The same slowdown happens with gfortran as well. I use Linux Debian 7.0.

Here are some profiling examples (using Intel Vtune) that show the delay inside one library for the original system. Small case: Small case Bigger case, same library: Bigger case

I expected some overhead but not that significant... Is this normal? Is it due to the pointer association at each driver call? Or some optimizations are disabled? Or simply the passing of a derived type instead of intrinsic? Should the associate construct cost that much?

This was cross-posted on https://software.intel.com/en-us/forums/topic/510037

Thanks in advance,

Upvotes: 3

Views: 821

Answers (1)

weymouth
weymouth

Reputation: 541

I'm not sure what you're looking for in terms of an answer... My experience with fortran oop and pointers is that, yes, that cause some fairly significant overhead.

I used OOP to write a fluid dynamics code for students - and it is safe and readable which is why I used OOP. But when I profiled the code I found that taking out the pointer references in some key parts of the code (the iterative pressure solver) gave me a speed up of a factor of two (~4 minutes run time down to 2).

So, pointers adding .2s doesn't seem impossible, but I can't say if that is your only issue from the information given. I guess a tip might be to develop with OOP (which was very fast and safe), and then optimize the pieces that actually matter for performance.

Upvotes: 2

Related Questions