Rate counter: Difference between revisions

=={{header|Fortran}}==

Standard Fortran does not offer facilities for starting another task, nor for monitoring such a task's consumption of cpu time against clock time. However, a program can monitor its ''own'' usage by invoking a suitable routine at appropriate points in its computation, say on each new iteration of its outermost DO-loop, and thus generate progress reports that could also include an estimated time of finishing. This requires access to system timers, usually achieved via invocations of special routines that are often specific to an installation. But F90 introduced the intrinsic <code>CALL CPU_TIME(T)</code> that returns a "processor-dependent approximation of the processor time in seconds" in <code>T</code> a floating-point variable.

Similarly, an installation may offer local routines to report the date and time, and F90 has introduced an intrinsic that can be invoked as <code>CALL DATE_AND_TIME(VALUES = MARK)</code> where MARK is an eight-element integer array, rather exhaustingly returning year, month, day, minutes from GMT (or UT, ''etc''), hour, minute, second, milliseconds.

So, in <lang Fortran> DO I = FIRST,LAST

IF (PROGRESSNOTE(I - FIRST,LAST - FIRST)) WRITE (6,*) "Reached ",I,", towards ",LAST

...much computation...

END DO</lang>

Function PROGRESSNOTE is invoked at the start of the iteration, with its first parameter stating how many steps have been completed (initially, none: this restarts its timers) and the second indicates how many are to be made. The function notes whether sufficient clock time has elapsed (more than six seconds, for example) and if so, returns ''true'' after starting an output line with a standard report giving an estimated time to run and an estimated time (and date, if not the current day) of completion. This line is not terminated; the invoking routine provides its own progress message, tailored to the task it is working through. For instance,

<pre>

Standard progress report|Tailored message.

ETF + 6·2hrs!@Monday 17/ 7/2017 5:23:25·013am. 0% Dumping Monday 3/ 2/1749.

ETF + 6·2hrs!@Monday 17/ 7/2017 5:23:37·167am. 0% Dumping Sunday 9/ 3/1749.

ETF + 6·2hrs!@Monday 17/ 7/2017 5:26:06·383am. 0% Dumping Friday 11/ 4/1749.

ETF + 6·1hrs!@Monday 17/ 7/2017 5:21:23·397am. 0% Dumping Friday 16/ 5/1749.

</pre>

Thus, the user waiting at the computer screen can know to go for a walk, or not.

Incidentally, on windows systems at least, frequent invocations of the date and time routine can cause execution to run ''much'' slower, or crash the system. A loop waiting for the system's DATE_AND_TIME result to attain a specified value will instead cause a crash.