Hi...

I am using an array of pointers in FORTRAN 90 where those points store
the address of a linked list. I Would like to know if when I use an
array of pointers is neccesary more RAM memory to store these datas. Is
possible to know how much percent it increase ??


here is an example of an array of pointers , where the array eul_pts
store the current pointer for each cell of an adapative mesh... is
correct the notation?

Do i = ig-nbc,ig+nx-1+nbc
   Do j = jg-nbc,jg+ny-1+nbc
      eul_pts(i,j)%em_pt(i,j)=curr_aux
   end do
end do  

Millena

In article <1127758349.567198.214370@z14g2000cwz.googlegroups.com>,
	"Millena" <millena.villar@gmail.com> writes:

> I am using an array of pointers in FORTRAN 90 where those points store
> the address of a linked list. I Would like to know if when I use an
> array of pointers is neccesary more RAM memory to store these datas. Is
> possible to know how much percent it increase ??
> 
> 
> here is an example of an array of pointers , where the array eul_pts
> store the current pointer for each cell of an adapative mesh... is
> correct the notation?
> 
> Do i = ig-nbc,ig+nx-1+nbc
>    Do j = jg-nbc,jg+ny-1+nbc
>       eul_pts(i,j)%em_pt(i,j)=curr_aux
>    end do
> end do  
> 

You need to provide more information.  In particular, we
need to know the definition of your derived type.

-- 
Steve
http://troutmask.apl.washington.edu/~kargl/

In article <1127758349.567198.214370@z14g2000cwz.googlegroups.com>,
 "Millena" <millena.villar@gmail.com> wrote:

> I Would like to know if when I use an
> array of pointers is neccesary more RAM memory to store these datas. Is
> possible to know how much percent it increase ??

Well, for a start, there is no such thing as an array of pointers in 
Fortran. The closest thing is an array of derived type, where the 
derived type has a pointer component. From your example, this is almost 
certainly what you are talking about.

If you want precise size numbers, that is compiler-specific. But as a 
rough approximation, a pointer to an array is going to need to have room 
to store the base address of the array, plus the lower bound, size, and 
stride for each rank. Some compilers might plausibly also store the 
upper bound for each rank, although that is at least largely redundant.

Note that the additional size used by a pointer has nothing at all to do 
with the size of the array - only with its rank. So it is pretty much 
meaningless to ask about a percentage.

On the whole, unless you have an awful lot of small arrays, the extra 
space used for pointers is negligible. That's because the extra size for 
the pointer is not proportional to the array size.

Since your sample arrays are of rank 2, assuming 3 values per rank, plus 
a base address, that is about 7 values per pointer. Round up a bit to 
about 10 in case the particular implementation stores some extra data. 
Assume 8 bytes (64-bits) per value; many implementations will use 4 
bytes, but assume 8 to be pessimistic, as some use that much. That adds 
up to about 80 bytes per array. If you have a million of these arrays, 
that's still only about 80 megabytes, which is a fair amount of storage, 
but if you have a million arrays, odds are high that your application is 
using a lot more than 80 megabytes anyway.

It is *POSSIBLE* to have cases where the extra storage for pointers is 
important, but that is an unusual edge case. Other efficiency issues 
than space are much more likely to be pertinent.

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

Hi Steve,
below there are the derived type that I am using, it is a little
extensive and confuse... but the important thing is that my pointer
store 5 or 6 informations and I will have a hundred of arrays of
pointers in my code.  I hope that it  show what I am implementing...

thanks in advance
Millena

Type grid_components
	Integer :: ix ,iy  ,mx ,my , iu, ip
	Integer:: iCoord
 End Type grid_components

 Type level_components
    Double precision:: hx ,hy
    Type(grid_components) :: grid
    Type(level_components), Pointer :: next
 End Type level_components

Type EL_pointer
   Type(level_components),Dimension(:,:),Pointer::em_pt
End type EL_pointer
Type(EL_pointer),allocatable,dimension(:),save::ptarray_EL

Subroutine self_address(Sx,Sy,ig,jg,nx,ny,curr_aux,eul_pts)
Implicit None
Integer::ig,jg,nx,ny,i,j,&
         Sx,Sy

Type(level_components),Pointer::curr_aux
Type(EL_pointer),dimension(ig-nbc:ig+nx-1+nbc+Sx,jg-nbc:jg+ny-1+nbc+Sy)::eul_pts

  Do i = ig,ig+nx-1
     Do j = jg,jg+ny-1
        eul_pts(i,j)%em_pt(i,j) = curr_aux
     End do
  End do

End Subroutine self_address

Hi Richard,

my concern is that when I implemented the array of pointers was
necessary  to obtain more RAM memory.  Now I really can't imagine what
is leading this increase in the merory mainly if I am taking care in
store the datas dinamicaly.

after the array of pointers I was runing my code in a machine with 512M
now I have to use one with 1.4G.  Perhaps the dinamic allocation of a
array of pointers can demand more memory... Is possible ??

thank you
Millena

Millena wrote:
| Hi...
| 
| I am using an array of pointers in FORTRAN 90 where those points store
| the address of a linked list. I Would like to know if when I use an
| array of pointers is neccesary more RAM memory to store these datas. Is
| possible to know how much percent it increase ??

For what it's worth, Visual Fortran pointer descriptor format (on 32-bit 
systems) is:

- 4 bytes for a pointer-to-scalar (same as C void*)
- for a pointer-to-array, 5 (Compaq) or 6 (Intel) dwords header,
  plus 3 dwords per each dimension, meaning 32 (48) bytes for
  a 2-D array.

You can find for yourself the figures for your compiler using:

type foo
   integer, pointer:: p(:)    !or p(:,:)
end type foo

type(foo):: f
write(*,*) size(transfer(f,(/" "/)))

-- 
 Jugoslav
___________
www.xeffort.com

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

Millena wrote:

> after the array of pointers I was runing my code in a machine with 512M
> now I have to use one with 1.4G.  Perhaps the dinamic allocation of a
> array of pointers can demand more memory... Is possible ??

 From another of your posts, I saw a mention of "hundreds" of pointers. 
That is not within several orders of magnitude of plausible for a cause 
of your memory problems. Let me round your "hundreds" up to a thousand, 
and my size estimate for pointer overhead up to 100 bytes. That gets up 
to about 1 megabyte. No. This just is not even close to plausible. You 
are looking in the wrong direction if you are looking there.

I would find it much more plausible that you have a memory leak - where 
you repeatedly allocate pointers and fail to deallocate them. That is a 
very common problem with pointers. There are also lots of other common 
problems with using pointers, but the overhead of pointer storage just 
is not one except in the most unusual of edge cases, which is clearly 
*NOT* what you have - not if you only have "hundreds" of arrays. Not 
even if you have thousands. You need to have more like millions before 
it would be plausible as an issue.

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain