home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / sci / engr / 2518 < prev    next >
Encoding:
Text File  |  1993-01-21  |  5.0 KB  |  121 lines
  1. Newsgroups: sci.engr
  2. Path: sparky!uunet!gatech!usenet.ins.cwru.edu!wsu-cs!nova!seeta
  3. From: seeta@eng.wayne.edu (Seetamraju UdayaBhaskar Sarma)
  4. Subject: Re: Help with CPU internal clock - the summary!
  5. Message-ID: <1993Jan21.214349.17446@cs.wayne.edu>
  6. Sender: usenet@cs.wayne.edu (Usenet News)
  7. Reply-To: seeta@eng.wayne.edu
  8. Organization: College of Engineering, Wayne State University, Detroit Michigan, USA
  9. References: <21JAN199311283372@ariel.lerc.nasa.gov>
  10. Date: Thu, 21 Jan 1993 21:43:49 GMT
  11. Lines: 108
  12.  
  13.  
  14. If Ur running the program on Sun workstations or on System Variants,
  15. then use the following command
  16.  
  17.     time Fortran_Prog
  18.  
  19. where the second word is to be replaced by the name of the fortran executable
  20. (that is Ur program).
  21.  
  22. On a multi-user system (Why even a multi-tasking system like OS/2) U cannot
  23. expect to determine the total execution time the way U did...
  24.  
  25. Seetamraju Udaya Bhaskar Sarma
  26. (email : seetam @ ece7 . eng . wayne . edu)
  27.  
  28. In article 21JAN199311283372@ariel.lerc.nasa.gov, ecaxron@ariel.lerc.nasa.gov (Ron Graham) writes:
  29. -+>Here is the original question:
  30. -+>
  31. -+>We have an application where we are trying to estimate the order of
  32. -+>a certain algorithm (whether O(N), O(N^2), etc.) by running it a certain
  33. -+>number of times for various values of N.  We measure the CPU time used
  34. -+>by the algorithm using the FORTRAN "SECNDS" command, executing it just 
  35. -+>before and just after the algorithm runs through its paces.
  36. -+>
  37. -+>What we are finding is that the CPU measure we get back varies wildly,
  38. -+>even for large values of N (~250) and for large numbers of runs (~30).
  39. -+>The questions are as follows:
  40. -+>
  41. -+>(1) Are there aspects of the SECNDS command we don't know about, such as
  42. -+>
  43. -+>    o  sensitivity to system functions (user load, time of day, etc.)
  44. -+>    o  inherent uncertainty
  45. -+>
  46. -+>(2) Is there a more reliable way to estimate the order of the algorithm?
  47. -+>
  48. -+>As you have guessed, we're running in FORTRAN, we're on a shared system,
  49. -+>and we're not taking advantage of parallel processing or any other advanced
  50. -+>programming tool.
  51. -+>
  52. -+>And here is a summary of responses:
  53. -+>
  54. -+>**********************************************************************
  55. -+>
  56. -+>From:    curran@pegasus.hks.com (Bill Mills-Curran)
  57. -+>
  58. -+>The VMS documentation for SECNDS ($ HELP FORTRAN INTRINS SECNDS) shows
  59. -+>that it is measuring wall clock time.  Try the C function "clock".
  60. -+>You can call it quite easily from FORTRAN.  Note that it returns an
  61. -+>integer which counts hundreths of a second used in the current
  62. -+>program.
  63. -+>
  64. -+>**********************************************************************
  65. -+>
  66. -+>From: mpaul@unlinfo.unl.edu (marxhausen paul)
  67. -+>
  68. -+>This is no help, but estimating CPU time usage is tough even on dedicated
  69. -+>single-user computers like PCs and similar - much of the "benchmarking"
  70. -+>that goes on in popular computer magazines points this out. Hardware 
  71. -+>issues such as memory and disk cacheing, drive access times, etc. all 
  72. -+>make it hard to get objective results.
  73. -+>
  74. -+>In the case of a multiuser computer, things are much worse in this regard.
  75. -+>The system has no real way to eliminate the delays imposed by swapping your
  76. -+>process in and out, and the hardware delays are almost completely unpre-
  77. -+>dicatable since the machine is servicing so many other requests at once.
  78. -+>
  79. -+>**********************************************************************
  80. -+>
  81. -+>From: kk881595@princeton (kevin knappmiller)
  82. -+>
  83. -+>Timing commands on multitasking systems are often tricky if you
  84. -+>want actual execution times.  What is the system you are using?
  85. -+>I would guess that your command is just sampling the system clock
  86. -+>giving real time not execution time.
  87. -+>
  88. -+>It has been my experience that you have to do something slightly 
  89. -+>different on almost every system.  One good choice might be
  90. -+>to use the UNIX "time" command, and stucture your code so that
  91. -+>the entire (or nearly) call execution time was taken by the
  92. -+>algorithm.  That is if you are using a UNIX with "time".
  93. -+>
  94. -+>**********************************************************************
  95. -+>
  96. -+>From: mwj%se17@se01.wg2.waii.com (Mike Johnson)
  97. -+>
  98. -+>To a feeble-minded codeslinger like myself, the best way to determine the 
  99. -+>order of an algorithm is by inspection. For example, I know that a bubble 
  100. -+>sort or insertion sort is O(N**2), because, in the worst case, N comparisons 
  101. -+>may be required to put each of the N data items in its place. I know that 
  102. -+>a quicksort is O(N*log N), because log N operations are required for each 
  103. -+>of the N data items.  (By log N, I mean the base 2 logarithm of N.) 
  104. -+>
  105. -+>**********************************************************************
  106. -+>
  107. -+>Unfortunately, the algorithm is simply too much for us to estimate by
  108. -+>inspection with the time we have at hand.  We were forced to scrap it,
  109. -+>do to the need for a quick turnaround on engineering time.
  110. -+>
  111. -+>But the insight on clock time and run time measurement really helped us
  112. -+>reach that decision in a hurry.  Thanks to all who responded.
  113. -+>
  114. -+>RG
  115. -+>
  116. -+>Who became an engineer thinking "free-body diagrams" might be interesting.
  117.  
  118.  
  119.  
  120.  
  121.