CPU_TIME and Others: I need solution for F90 and F03.

[atru]

Unfortunately, I can not run the following construct under Fortran 90-2003. Have anybody any idea how to move the problem? I see the following message: Warning: The [...] intrinsic function was not part of Fortran 90.

INTEGER(KIND=4), ALLOCATABLE :: T_HZ(:)
INTEGER(KIND=4) :: HZ, SYSTEM_CLOCK_BEGIN, SYSTEM_CLOCK_END
REAL(KIND=4) :: CPU_TIME_BEGIN, CPU_TIME_END          
REAL(KIND=8) :: SECONDS_OF_SYSTEM_CLOCK, MINUTES_OF_SYSTEM_CLOCK
...
ALLOCATE (T_HZ(NUMBER_OF_PROCESSORS()))
CALL SYSTEM_CLOCK (COUNT_RATE=HZ)
CALL SYSTEM_CLOCK (COUNT=SYSTEM_CLOCK_BEGIN)
CALL CPU_TIME (CPU_TIME_BEGIN)
...
CALL SYSTEM_CLOCK (COUNT=SYSTEM_CLOCK_END)
...
T_HZ=SYSTEM_CLOCK_END-SYSTEM_CLOCK_BEGIN
SECONDS_OF_SYSTEM_CLOCK=REAL(SUM(T_HZ))/(REAL(HZ)*SIZE(T_HZ))
MINUTES_OF_SYSTEM_CLOCK=SECONDS_OF_SYSTEM_CLOCK/60.D0
CALL CPU_TIME (CPU_TIME_END)

[TimP]

I can't guess why you have broadcast your time across an array and then averaged it, but it may be OK.

For F2003, it would be better to use a larger KIND for the SYSTEM_CLOCK arguments.

No one writes pure f90 any more, it doesn't make sense to avoid cpu_time on account of it requiring f95.

[atru]

TimP (Intel)

I have received the following messages for F95. What’s wrong? Now according to your advice – KIND=8 for the SYSTEM_CLOCK arguments.

Warning: Fortran 95 does not allow this intrinsic procedure.   [NUMBER_OF_PROCESSORS]
ALLOCATE (T_HZ(NUMBER_OF_PROCESSORS()))
---------------^
Warning: An argument of the SYSTEM_CLOCK intrinsic that is not of type default integer is not standard F95.   [HZ]
CALL SYSTEM_CLOCK (COUNT_RATE=HZ)
------------------------------^
Warning: An argument of the SYSTEM_CLOCK intrinsic that is not of type default integer is not standard F95.   [SYSTEM_CLOCK_BEGIN]
CALL SYSTEM_CLOCK (COUNT=SYSTEM_CLOCK_BEGIN)
-------------------------^
Warning: An argument of the SYSTEM_CLOCK intrinsic that is not of type default integer is not standard F95.   [SYSTEM_CLOCK_END]
CALL SYSTEM_CLOCK (COUNT=SYSTEM_CLOCK_END)

[Steven_L_Intel1]

NUMBER_OF_PROCESSORS is always going to return 1 in Intel Fortran. It is an obsolete HPF intrinsic.

Why do you need to be strictly compliant with Fortran 90?  Which other compilers will you be using?

[atru]

4 Steve

Frankly speaking my IVF 10.1 gives me a warning message for all types of Fortran.

Project -> Properties -> Diagnostics -> Warn on non-standard Fortran -> (/stamdf90|/stamdf 95|/stamdf 03)

-- > Why do you need to be strictly compliant with Fortran 90?  Which other compilers will you be using?

I would like to be of compliant with Fortran 03-08, but I have too many old codes. I must write many of them again to satisfy the requirements of Fortran 03-08. For example, I should delete all arithmetic IFs.
Only Intel compiler.

[TimP]

The messages on system_clock are telling you just what is expected; selected_int_kind(10) support in system_clock was first required by f03.

Most compilers support this much of f03; the only argument I've seen for checking at the f95 level is that several compilers have further to go to support f03 and it is hard to predict which features will be missing.

Arithmetic ifs are supported by all compilers even though they would not have been written in the last 35 years.  I've generally run such source code through the old tools to convert to  if..then..else/cycle/exit. Arounc 40 years ago we had compilers which generated an extra jump with logical IF but even then I never saw it proven as a significant performance question.  It's mainly a question of human readability.

[atru]

4 TimP (Intel)
Obviously you are right. It’s a question of human readability. But, probably, it’s also a question of style of writing I have got from an ancient coder. Any way IFs are not the things that cause a lot of trouble. I am looking for a solution for above-mentioned code. Say me that all is OK or correct it in such way that I will never see the warning messages. That is a goal of my topic. I feel I am about to reach that goal.

[Steven_L_Intel1]

Just don't ask for standards warnings if you don't want to see them. Please don't rewrite the code unless someone is telling you to remove anything not standard in F90 specifically. I would suggest just turning off the warnings.

[jimdempseyatthecove]

Excluding NUMBER_OF_PROCESSORS, refrain from using "INTEGER :: foo ... SYSTEM_CLOCK(foo)" IOW do not use default integer. Instead explicitly use INTEGER(2), INTEGER(4) or INTEGER(8), or parameter you define for this purpose.

Additional note, SYSTEM_CLOCK is based on the system realtime clock which is typically NOT a high frequency clock. You might want to consider using a different timing function if high precision clock values are desired.

Jim Dempsey

[atru]

Can anybody tell me whether the ETIME and DTIME will replace the above-mentioned code adequately? I have never used these functions.

[jimdempseyatthecove]

Have you considered:

progrmam yourProgram
use omp_lib
real(8) :: t0, t1
t0 = omp_get_wtime()
call YourCodeToBeTimed()
t1 = omp_get_wtime()
write(*,*) "Runtime = ", t1-t0

omp_get_wtime can be called from a non-OpenMP application (but does require the OpenMP library to be linked in.

Jim Dempsey

[TimP]

etime and dtime are legacy predecessors of cpu_time but don't offer significant additional utility on platorms which support f95.   Removing f95 intrinsics and replacing them by obsolete non-portable legacy functions may stop the compiler from warning you about compatibility with older standards, but this will cost you portability.

cpu_time was among the first intrinsics to be implemented in f90 compilers as an f95-compatible extension.   Even before f95 there were compilers which supported cpu_time but not dtime/etime.  You haven't answered the question about why you wanted compatibility with f90, but you really should check whether you could use a compiler which doesn't support the f95 timing intrinsics before you compromise your source code in that direction.

I doubt you could find a current compiler which doesn't offer at least partial support of the f2003 versions of these intrinsics, at least sufficient that there's no need to use the f90 subset.

[atru]

TimP (Intel)

Probably it was a big shock for everybody to see one person who writes in F90. Do not be in panic! I'm moving to Fortran 2003. But it takes an incredible amount of time to write again or edit the parts of old codes in order to prepare the perfect code of Fortran 2003. It has become a great number of the time-related functions in the modern Fortran. Can you recommend me the last versions of functions for CPU time, user time, operating time and etc.?

[Steven_L_Intel1]

You don't have to rewrite anything. But if you're adding timing code now, PLEASE use the standard intrinsics CPU_TIME and SYSTEM_CLOCK.

[atru]

The only good message this day. No change - no work. I am free!

[John_Campbell]

You might want to consider an alternative for elapsed time. WINAPI routine QueryPerformanceFrequency offers a much better solution.

John

[atru]

Thank you, John! It’s quite interesting. I will try to do it a little bit later. I think Steve and TimP provided me enough data for current stage.