home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / fortran / 3292 < prev    next >
Encoding:
Text File  |  1992-08-30  |  2.1 KB  |  47 lines
  1. Newsgroups: comp.lang.fortran
  2. Path: sparky!uunet!munnari.oz.au!metro!wonga
  3. From: wonga@chem.su.oz.au ()
  4. Subject: Performance diff between passed and stack arrays
  5. Message-ID: <1992Aug31.070836.541@ucc.su.OZ.AU>
  6. Sender: news@ucc.su.OZ.AU
  7. Nntp-Posting-Host: steam.chem.su.oz.au
  8. Organization: Sydney University Computing Service, Sydney, NSW, Australia
  9. X-Newsreader: Tin 1.1 PL4
  10. Date: Mon, 31 Aug 1992 07:08:36 GMT
  11. Lines: 34
  12.  
  13. For medium to large sized arrays, is there any difference in performance 
  14. between an array passed from main & creating the array within the subroutine
  15. on the stack? I realize that for very large arrays there is some default
  16. stacksize that it might exceed, where performance may be degraded. (my
  17. compiler informs me of this) but could this extrapolated back to smaller
  18. arrays. I.e. does smaller stacksizes neccessarily imply better perforamnce?
  19.  
  20. Is there any difference between an array declared in main's stack and
  21. one given common storage.
  22.  
  23. This sort of dilemma is a continual source of headaches for which it 
  24. seems there are three options:
  25.  
  26.     i) Pass portions of blank common to the subroutines to use as
  27.     workspace. This leads to lengthy parameter lists and messy
  28.     indexing arithmetic. 
  29.  
  30.     ii) Declare the temporary arrays in the subroutine itself.
  31.     This is apparently not suitable for large arrays and for arrays
  32.     where the required dimensions is not known in advance.
  33.  
  34.     iii) Use blank common in the subroutine, however
  35.     once again dynamic setting of array lengths is not possible.
  36.  
  37. Without resorting to dynamic memory allocation, I would say (i) was the 
  38. preferred option since the main module can abort the program if the
  39. size of the problem is too big and the other modules can be independent
  40. of PARAMETER statements. However, 90% of my main modules are invariably 
  41. devoted to indexing/memory arithmetic.
  42.  
  43. I would be interested to hear how others tackle this problem.
  44. -----------------------------------------------------------------------------
  45. Adrian Wong, Dept.of Theoretical Chemistry     wong_a@summer.chem.su.oz.au
  46. University of Sydney NSW 2006 Australia        061-2-692 4137
  47.