Fortran execution time

Question

I am new with Fortran and I would like to ask for help. My code is very simple. It just enters a loop and then using system intrinsic procedure enters the file with the name code and runs the evalcode.x program.

program subr1
  implicit none
  integer :: i,
  real    ::  T1,T2 

  call cpu_time(T1)
  do i=1,6320
    call system ("cd ~/code; ../evalcede/source/evalcode.x test ")
  enddo
  call cpu_time(T2)

  print *, T1,T2

end program subr1

The time measured that the program is actually running is 0.5 sec, but time that this code actually needs for execution is 1.5 hours! The program is suspended or waiting and I do not know why.

Answer 1

The CPU_TIME intrinsic measures CPU time consumed by the program itself, not including those of it's subprocesses (1).

Apparently most of the time is spent in evalcode.x which explains why the reported wallclock time is much higher.

If you want to measure wallclock time intervals in Fortran, you can use the SYSTEM_CLOCK intrinsic.

(1) Well, that's what GFortran does, at least. The standard doesn't specify exactly what it means.

Answer 2

note: this is more an elaborated comment to the post of Janneb to provide a bit more information.

As indicated by Janneb, the function CPU_TIME does not necesarily return wall-clock time, what you are after. This especially when timing system calls.

Furthermore, the output of CPU_TIME is really a processor and compiler dependent value. To demonstrate this, the following code is compiled with gfortran, ifort and solaris-studio f90:

program test_cpu_time
  real    ::  T1,T2 
  call cpu_time(T1)
  call execute_command_line("sleep 5")
  call cpu_time(T2)
  print *, T1,T2, T2-T1
end program test_cpu_time

#gfortran>]   1.68200000E-03   1.79799995E-03   1.15999952E-04
#ifort   >]  1.1980000E-03  1.3410000E-03  1.4299992E-04
#f90     >] 0.0E+0 5.00534 5.00534

Here, you see that both gfortran and ifort exclude the time of the system-command while solaris-studio includes the time.

In general, one should see the difference between the output of two consecutive calls to CPU_TIME as the time spend by the CPU to perform the actions. Due to the system call, the process is actually in a sleep state during the time of execution and thus no CPU time is spent. This can be seen by a simple ps:

$ ps -O ppid,nlwp,psr,stat $(pgrep sleep) $(pgrep a.out)
  PID  PPID NLWP PSR STAT S TTY          TIME COMMAND
27677 17146    1   2 SN+  S pts/40   00:00:00 ./a.out
27678 27677    1   1 SN+  S pts/40   00:00:00 sleep 5

• NLWP indicates how many threads in use
• PPID indicates parent PID
• STAT indicates 'S' for interruptible sleep (waiting for an event to complete)
• PSR is the cpu/thread it is running on.

You notice that the main program a.out is in a sleep state and both the system call and the main program are running on separate cores. Since the main program is in a sleep state, the CPU_TIME will not clock this time.

note: solaris-studio is the odd duck, but then again, it's solaris studio!

---

General comment: CPU_TIME is still useful for determining the execution time of segments of code. It is not useful for timing external programs. Other more dedicated tools exist for this such as time: The OP's program could be reduced to the bash command:

$ time ( for i in $(seq 1 6320); do blabla; done )

---

This is what the standard has to say on CPU_TIME(TIME)

CPU_TIME(TIME)

Description: Return the processor time.

Note:13.9: A processor for which a single result is inadequate (for example, a parallel processor) might choose to provide an additional version for which time is an array.

The exact definition of time is left imprecise because of the variability in what different processors are able to provide. The primary purpose is to compare different algorithms on the same processor or discover which parts of a calculation are the most expensive.

The start time is left imprecise because the purpose is to time sections of code, as in the example.

Most computer systems have multiple concepts of time. One common concept is that of time expended by the processor for a given program. This might or might not include system overhead, and has no obvious connection to elapsed “wall clock” time.

_{source: Fortran 2008 Standard, Section 13.7.42}

On top of that:

It is processor dependent whether the results returned from CPU_TIME, DATE_AND_TIME and SYSTEM_CLOCK are dependent on which image calls them.

Note 13.8: For example, it is unspecified whether CPU_TIME returns a per-image or per-program value, whether all images run in the same time zone, and whether the initial count, count rate, and maximum in SYSTEM_CLOCK are the same for all images.

_{source: Fortran 2008 Standard, Section 13.5}