Using pointers versus allocatable arrays for scratch workspace

[gstalls]

In hopes of boosting code efficiency for a large numerical model, I am looking into replacing the current way of creating scratch workspace - allocate a large array, perform operations, deallocate - with pointers - point to one large array and save myself from many repeated opening and closings of an array.

However, there seems to be a mixed bag of opinions on pointer usage. Some of these concerns I share such as contiguity and memory leaks; while I believe the latter may be avoided with the contiguous attribute. Moreover, I have read that the use of pointers may prevent certain compiler optimizations.  

I have made a test script to assess the implementation of these two approaches. Here are the two tests that mimic how I have interpreted making scratch space:

do k=1,500
    ! Call the subroutine based on arg
    if (arg1=='pointer') then
      pt1(istr:iend,jstr:jend) => t1(istr:iend,jstr:jend,1) ! pointer remapping
      call pointer_test(pt1)
      nullify(pt1)
    else
      allocate(tmp(istr:iend,jstr:jend))
      tmp(:,:) = t1(istr:iend,jstr:jend,1)
      call temp_test(tmp)
      t1(istr:iend,jstr:jend,1) = tmp
      deallocate(tmp)
    endif
  enddo

Looking to better understand the use of pointers and why much of the Fortran community stands by allocatable arrays. I am using Intel's mpiifx 2021.14 compiler, if this is helpful, but am anticipating a broader discussion of pointers vs allocatable arrays. 

Thank you!

[jimdempseyatthecove]

Allocatables have the benefit that they are thread-safe .AND. will automatically deallocate (when allocated) on procedure exit.

Should your code be multi-threaded .AND. allocations take place within a parallel region, then you will have issues to work out (thread-safety and deallocations not in reverse order of allocations). This can be mitigated by having each thread containing its own storage area.

Should your allocations take place ONLY within sequential sections of code, then, and only then, consider allocating an appropriately sized (huge?) blob, then treat this blob as an auxiliary stack. *** you have the responsibility of assuring stack consistency upon return from procedure as well as avoiding creating "persistent" objects.

Jim Dempsey

[JohnNichols]

One could use Common Lisp, that has a number of advantages except speed.  Oh, the learning curve is steep.