[daip] Re: Regarding the 'AP size' in Aips

[Eric Greisen]

Subhashis Roy writes:
 > Hello,
 > 
 > I noticed before while using 'update.pl' that it asks for the AP size.
 > 
 > INSTALL.TEX says :
 > -----------------------
 > The {\tt PAPC.INC} file therein defines the pseudo array processor size
 > as 1.25 megawords (5 Megabytes) in most cases.  Before starting {\tt
 > INSTEP2}, you should check if your version has an archicture-specific
 > version of {\tt PAPC.INC} (these do: ALN, CRI, CVEX, IBM).  For systems
 > with 128 or more megabytes of main memory, you may want to increase the
 > AP size by editing the {\tt PAPC.INC} file.  As an example, on NRAO's
 > large-memory IBM and Sun systems, the {\tt APSIZE} variable in this file
 > is set to 21233664 (81 megabytes).  This is only useful for large scale
 > problems, in this case images of size 4k on a side, to allow various
 > \AIPS\ tasks to read in the image entirely to memory, and tends to
 > increase performance somewhat.
 > ------------------------------
 > 
 > My question is, if AP size is finally controlling the amount of memory 
 > to use for different tasks ?
 > 
 > (Given the large amount of RAM available nowadays, is it not proper for
 > AIPS to ask the OS to supply the required memory dynamically ? OS will
 > 'swap' automatically if the required RAM is not available.)
 > 

Fortran does not do dynamic memory allocation and all of AIPS is
written in Fortran.  We have worked out ways to do dynamic allocation
in the most critical cases.  There is very much too much code to
convert it all to dynamic allocation especially with only one
full-time programmer left in the project.  Fortran compilers still do
a good job of optimising the code in our current structure and I see
no reason for any wholesale changes.

The AP size does control IMAGR and other "Q" tasks, but FRING and
non-Q routines get their memory either dynamically or by traditional
means.

Eric Greisen