ALLOCATING VARIABLES and Execution Speed

[dajum]

I took a large program and put 10 arrays into a module and allocated those variables. Previously they had been in common blocks. I ran a sample input file both before and after the change. With the arrays in a common block the code ran in 102 seconds. With the arrays on the heap, the code took 195 seconds to run. Is this kind of speed penalty to be expected from moving arrays onto the heap? Several of the arrays are used as indexes into the other arrays so I expected it to run a little slower, but not a factor of almost 2.

Is there anywhere the effects are documented?

Thanks,

Dave

[Steven_L_Intel1]

Are they ALLOCATABLE or POINTER? If POINTER, that will disable a lot of optimizations. Typically there is very little penalty for using allocatable variables, but there is an extra level of indirection and some information not available at compile time, so you may see a difference.

[dajum]

REAL,allocatable :: HR(:)

integer,allocatable :: PT(:)

Is how they are defined in the module, so no they are not POINTERS. I expected the extra level of indirection, which I thought might only be 5 or 10% for the application. A lot of it doesn't even use these variables.

So now I'm not sure how to figure out why it runs so slow.

[jimdempseyatthecove]

Is this Debug build or Release build?
Debug build may perform additional work with respect to bounds checking for allocatable arrays than for fixed arrays.

See section in user guide, index"assumed-shape arrays", scroll down to Passing Array Arguments Efficiently.

Jim Dempsey

[dajum]

Jim,

Thanks for pointing me to that section. Learned something new there, and it might be an issue. I'll check into it. I am running in Release mode with all the optimizations on in both cases, and no extraneous checks.
I'm sure I'll figure out I did something silly.

Dave

[jimdempseyatthecove]

Sometimes it helps to look at the Dissassembly window or generate a .ASM file. You do not have to understand assembly for this purpose, just that more lines generally means slower code.

Note that your efforts of using explicit-shape and assumed-size arrays could potentially get undone by IPO (interprocedural optimizations). It shouldn't but you might want to verify this for yourself.

Jim Dempsey