 News |
FAQ
|
| Search
|
Home
|
| Getting Started | Documentation | Glish | Learn More | Programming | Contact Us |
|
| Version 1.9 Build 1367 |
|
Memory use can generally be split up between that required for dynamic allocations within the application, and that required for the binary executable itself.3.
For the sake of discussion, suppose the user is doing some interactive fiddling and image display while a standard-sized background continuum imaging task is computing.
It seems likely that the workhorse imaging programs will require access to all polarizations at once. In ``image'' space, then the standard problem size is:
The factor of 5 comes from requring 4 polarizations in the output (and input) images, but assuming that the beam is scalar. I also assume that we take advantage of symmetry, i.e. the Complex images can be 1/2 the size and transform into full-sized real images.
The size of the cache required to go through the MeasurementSet should be fairly small (equivalent to a few rows). The subtables are also generally small. So, the continuum case memory use is dominated by the image sizes. Inflating by 25% on general principles to allow for various other application work areas brings the size to 25M.
The spectral line problem is considerably cheaper, assuming only one plane needs to be kept in memory at a time.
Of course applications which do not require an entire image plane in memory at once could and should be coded to use a ``sliding window.'' The Image iteration model should make this straightforward.
AipsView uses memory mapped I/O when the underlying FITS file is floating point, and the host architecture is big-endian. When this is not the case it will pull the entire image into memory, which is unacceptable for medium to large spectral line cubes. Normally however AipsView uses memory mapped I/O for the data, which should result in a buffer which is sized to be ``nice'' in the current processing environment. Pixmaps are however probably kept in local memory, so a couple of 1024 x 1024 images will result in about 2M of memory allocation.
Glish users will use memory directly in local variables, and in its external clients (e.g., the tableclient). There is nothing restricting how much memory the user wishes to stick in local variables. Moreover the tendency of Glish to promote from single to double precision can exacerbate these space problems. In practice, I expect that users will learn that bringing in whole Images, or entire column of visibility data, is usually a bad thing to do. They will either set an ``xinc,'' or will iterate through all the data. I'll arbitrarily set the amount of allocations in Glish and its clients to 3M. This brings the amount of allocated memory to about 30M.
AipsView is about 1.4M (shared X libraries). Glish and a client or two should be 5M or less (shared Glish libraries). Imager is 10M.
While the Glish size seems a little large (statics?), Imager is clearly the largest offender. Presumably this is largely caused by template instantiations of similar functions.
Moreover, unless common library functionality is in a shared library, this bloat will add up linearly with the number of processes.4. Moreover, large executable sizes imply slow startup of the executables if they must be fetched over the network (for example, via NFS).
The sum of the allocated memory estimates and executable size estimates is about 46.5M. Adding about 16M for the operating system takes us to 62.5, just under the amount of memory in our canonical machine.
While we can conclude that this standard problem would run reasonably well in our standard machine, a larger problem (e.g., 2k x 2k ) would cause the standard machine to swap heavily.