Memory usage in fortran when using an array of derived type with pointer

Question

In this sample program I'm doing the same thing (at least I think so) in two different ways. I'm running this on my Linux pc and monitoring the memory usage with top. Using gfortran I find that in the first way (between "1" and "2") the memory used is 8.2GB, while in the second way (between "2" and "3") the memory usage is 3.0GB. With the Intel compiler the difference is even larger: 10GB versus 3GB. This seems an excessive penalty for using pointers. Why does this happen?

program test
implicit none

  type nodesType
    integer:: nnodes
    integer,dimension(:),pointer:: nodes 
  end type nodesType

  type nodesType2
    integer:: nnodes
    integer,dimension(4):: nodes 
  end type nodesType2

  type(nodesType),dimension(:),allocatable:: FaceList
  type(nodesType2),dimension(:),allocatable:: FaceList2

  integer:: n,i

  n = 100000000

  print *, '1'
  read(*,*)
  allocate(FaceList(n))
  do i=1,n
    FaceList(i)%nnodes = 4
    allocate(FaceList(i)%nodes(4))
    FaceList(i)%nodes(1:4) = (/1,2,3,4/)
  end do
  print *, '2'
  read(*,*)

  do i=1,n
    deallocate(FaceList(i)%nodes)
  end do
  deallocate(FaceList)

  allocate(FaceList2(n))
  do i=1,n
    FaceList2(i)%nnodes = 4
    FaceList2(i)%nodes(1:4) = (/1,2,3,4/)
  end do
  print *, '3'
  read(*,*)

end program test

The background is local grid refinement. I chose the linked list to easily add and remove faces. The number of nodes is 4 by default but can become higher depending on the local refinements.

Answer 1

I don't actually know how fortran compilers work, but based on the language features, I can take a guess.

Dynamic arrays in fortran come with meta-data to work with intrinsic functions like shape, size, lbound, ubound, and allocated or associated (allocatable vs pointers). For large arrays, the size of the meta-data is negligible, but for tiny arrays, like in your case, it can add up. In your case, the size 4 dynamic arrays likely have more meta-data than real data, which is leading to your memory usage balloon.

I'd strongly recommend against dynamic memory at the bottom of your structures. If you're writing a code that deals with physical systems in some number of dimensions, you can set it as a macro and recompile. If you dealing with graphs, you can statically allocate an upper bound on the number of edges or the likes. If you are dealing with a system that actually needs fine-grain dynamic memory control, then it is probably best to switch to C.

Answer 2

As maxhutch has pointed out, the problem is probably the sheer number of separate memory allocations. On top of the metadata, though, there's probably whatever additional data and alignment the memory manager needs, i.e. it is probably rounding each allocation up to some multiple of 64 bytes or more.

To avoid allocating a small chunk for each node, you could try allocating each node a portion of a pre-allocated array:

integer :: finger
indeger, dimension(8*n) :: theNodes

finger = 1
do i=1,n
    FaceList(i)%nodes => theNodes(finger:finger+FaceList(i)%nnodes-1)
    finger = finger + FaceList(i)%nnodes
end do

My Fortran is a bit rusty, but the above should work, if not in principle.

You'd still have the overheads of whatever your Fortran compiler thinks it needs to store for a POINTER type, but you won't have the memory manager overheads.

Answer 3

Oh. This is the same problem I suffered. This question is very old, but I suggest a little different code style. My problem was allocatable statement array in derived data type, as follow code.

type :: node
  real*4,dimension(:),allocatable :: var4
  real*8,dimension(:),allocatable :: var8
end type node

type(node),dimension(:),allocatable :: nds

imax = 5000
allocate(nds(imax))

From some test, I confirmed that if I used the allocatable statement or pointer statement in the derived type as follow code about four cases, memory leakage happen very large. In my case, I red the file of 520MB size. But the memory usage was 4GB at release mode on intel fortran complier. That is 8 times bigger!

!(case 1) real*4,dimension(:),allocatable :: var4
!(case 2) real*4,dimension(:),pointer :: var4
!(case 3) real*4,allocatable :: var4(:,:)

!(case 4) 
type :: node(k)
  integer,len :: k = 4
  real*4 :: var4(k)
end type node

Memory leakage doesn't happen when I use allocatable or pointer statement without derived type. In my opinion, if I declare the allocatable or pointer type variable in derived type and large allocate the derived type variable not allocatable variable in the derived type, memeory leakage occurs. To solve this problem, I changed my code that does not include derived type as follow code.

real*4,dimension(:,:),allocatable :: var4 
! array index = (Num. of Nodes, Num. of Variables)

or how about this style?

integer,dimension(:),allocatable :: NumNodes ! (:)=Num. of Cell or Face or etc.
integer,dimension(:),allocatable :: Node     ! (:)=(Sum(NumNodes))

NumNodes variable means the number of nodes on each face and Node variable is the node numbers matching NumNodes variable. Maybe memory leakage is not occurred in this code style, I think.