SAOimage permits monitoring of the time required to allocate memory. This allocation need only be done once for images of a given size. However, if extremely large images are loaded, subsequent smaller images will suffer from the paging implied by the size of the largest previous image. SAOimage appears to read first, then process the image.
ximtool also takes time for initial allocation of memory, but the time required for the subtasks is harder to determine. Also, the behavior of ximtool is affected by the graphcap configuration used to drive it from IRAF. ximtool appears to read the image in small pieces and process as it goes.
When an image will fit in RAM SAOimage is four times faster. When an image is too big to fit in RAM ximtool is faster.
In each of these cases the display tool image window was 512x512 pixels.
image size SAOimage IRAF/ximtool 2k x 8k 10 s to allocate mem 8 s to read image 7 s to process -- 15 s after first time 1:00 into matched frame 8k x 4k 10 s to allocate mem 25 s to read image 11 s to process -- 36 s after first time 2:15 into matched frame 8k x 8k 50 s to allocate mem, paging ~8 m to read image, paging ~3 m to process, paging -- ~11 m while paging 5:00 into matched frameThese timings are consistent with a SCSI transfer rate of ~2Mbytes/s.
With Digital Unix on alpha SAOimage and ximtool perform approximately equally when all of the image fits within the available RAM.
SAOtng version 1.5 is reported to build successfully on alpha, but it repeatedly suffered from SEGVIO when operating on radec.
ESORTD is apparently not 64-bit clean at this time. The executable did build and run successfully. The underlying pattern of pixel values was visible, but the displayed images had values which were nonsensical.
In each of these cases the display tool image window was 512x512 pixels.
image size SAOimage IRAF/ximtool 2k x 8k 10 s to read image 13 s into matched frame 1 s to process IRAF processing times 16->16 rfits 18 s 16->32 rfits 26 s int imarith + 8 s (cache) int imarith + 27 s (nocache) int->fp imarith / 35 s (nocache) int->fp imarith / 15 s (cache) fp imarith + 57 s (nocache) fp imarith + 15 s (cache) fp imarith / 15 s (cache) fp imfunc sqrt 15 s (cache) fp imfunc log 15 s (cache) fp imfunc sin 15 s (cache) 16->16 wfits s 8k x 4k 21 s to read image 26 s into matched frame 2 s to process IRAF processing times 16->16 rfits 43 s 16->32 rfits 59 s int imarith + 15 s (cache) int imarith + 56 s (nocache) int->fp imarith / 72 s (nocache) int->fp imarith / 30 s (cache) fp imarith + 114 s (paging) fp imarith / 122 s (paging) fp imfunc sqrt 83 s (nocache) fp imfunc sqrt 31 s (cache) fp imfunc log 31 s (cache) fp imfunc sin 31 s (cache) 32->16 wfits 16 s 8k x 8k 40 s to read image 42 s into matched frame 4 s to process IRAF processing times 16->16 rfits 67 s 16->32 rfits 112 s int imarith + 107 s (nocache) int imarith / 70 s (cache?) 16->16 wfits 71 s Disk space limitations precluded the binary floating point tests with the full size images, but it is clear that paging would be happening with radec's current configuration.These timings are consistent with a SCSI transfer rate of ~4Mbytes/s. Because Digital Unix on alpha performs lazy evaluation of VM there is not a long time of memory allocation visible before each operation as there is with SunOS.