Dear Xuebin,
I disagree with the below statement at least in the most general form. I
use pointers all the time in the QMMM code and they are just as quick as
using allocatable arrays. The problem comes if they are used in a c like
fashion which is not what I was advocating.
For single dimension arrays a pointer is fine as the pointer just points
to the beginning of a single linear block of memory that you can traverse
linearly just as you would an allocatable array. Here I see no difference
between a pointer and an allocatable array.
When you move to multidimension arrays things become more complicated
since there are essentially two ways of doing things. The first, and
arguably what you should use, is the fortran way of doing things. This has
a single pointer to a linear block of memory that you can just treat as
being multidimensional by knowing the stride size of all dimensions but
the last one. This still allows linear memory traversal.
The second option is to use the 'c' style which is to allocate a 1 D
array of pointers that contains pointers to the second dimension and so
on. So arrays of pointers. This is a bad idea with regards to optimisation
as it does not guarantee linearity in memory. It also requires the lookup
of an address to get the location of an element in memory.
So, as long as we stick to the fortran approach I don't see any problem.
Somebody please correct me if you have evidence that pointers really are
worse performance wise. To date I have not come across any problems...
With regards to memory errors I always figure exactly the same thing
happens with allocatable arrays. As long as we all program in a concise
fashion - that is avoiding things like ****x etc etc., then there should
not be any problems. This said I recommend running your parts of the code
through memory checkers like valgrind on a regular basis. This can uncover
a lot of potential problems caused by array out of bounds errors etc.
Just my 2c... I don't want to get into a religious c vs fortran war,
suffice to say things can be done the wrong way in both languages...
All the best
Ross
/\
\/
|\oss Walker
| Department of Molecular Biology TPC15 |
| The Scripps Research Institute |
| Tel: +1 858 784 8889 | EMail:- ross.rosswalker.co.uk |
|
http://www.rosswalker.co.uk <
http://www.rosswalker.co.uk/> | PGP Key
available on request |
Note: Electronic Mail is not secure, has no guarantee of delivery, may not
be read every day, and should not be used for urgent or sensitive issues.
_____
From: owner-amber-developers.scripps.edu
[mailto:owner-amber-developers.scripps.edu] On Behalf Of Xuebin Qiao
Sent: Tuesday, November 08, 2005 18:52
To: amber-developers.scripps.edu
Subject: Re: amber-developers: Compile AMBER9 on SGI
In fortran, AFAIK, be care of using pointer, this make your code more like
C. The side effect is the more times you use pointer, the less chance your
compiler can optimize your code (Alias Opti.). This is one of why, in
numerical computation, fortran can be generally faster than C without
manual optimization.
Best regards
qxb
On 11/9/05, Ross Walker <ross.rosswalker.co.uk> wrote:
> I am pretty reluctant to require a Fortran 2003-compliant compiler for
> Amber 9. Is there any easy way to not have to use
> allocatable arrays inside
> user-defined types?
I think this can be done with pointers instead of 'traditional'
allocatable
arrays. E.g.
type chang_miller_type
_REAL_, allocatable :: q( :)
_REAL_, allocatable :: d( :)
_REAL_, allocatable :: k(:,:)
.
.
.
end type
becomes:
type chang_miller_type
_REAL_, pointer :: q( :)
_REAL_, pointer :: d( :)
_REAL_, pointer :: k(:,:)
.
.
.
end type
This 'should' be completely compatible and, assuming they don't use:
if(allocated(blah))
then no other changes are necessary. If they do use the allocated() call
then you need to go through and set every pointer initially to null and
then
instead of if (allocated()) just check if the pointer is still null.
Pointers are also much more versatile since you can use the pointer
assignment command to flip arrays rather than doing a copy. E.g.
Instead of
do
! fill p with data based on pold and new stuff...
...
! copy p into pold to use as the starting point for next time...
pold(1:natom) = p(1:natom)
end do
Or similar pseudo code... You can do
_REAL_, dimension(:), pointer :: temp_ptr
do
! fill p with data based on pold and new stuff...
...
! copy p into pold to use as the starting point for next time...
!Store the pointer to p
temp_ptr => p
p => pold
pold => temp_ptr
end do
This allows you to flip flop back and forth between the two arrays without
actually doing an array copy.
Any volunteers for going through all the evb code???
All the best
Ross
/\
\/
|\oss Walker
| Department of Molecular Biology TPC15 |
| The Scripps Research Institute |
| Tel: +1 858 784 8889 | EMail:- ross.rosswalker.co.uk |
|
http://www.rosswalker.co.uk | PGP Key available on request |
Note: Electronic Mail is not secure, has no guarantee of delivery, may not
be read every day, and should not be used for urgent or sensitive issues.
--
... there have been two really clean,
consistent models of programming so far:
the C model and the Lisp model.
These two seem points of high ground,
with swampy lowlands between them.
--Paul Graham
Received on Wed Apr 05 2006 - 23:49:51 PDT
