forums.silverfrost.com

[Anonymous]

I'm kind of new to this Fortran lark and have recently been trying to optimise a large code. I've been using the system_clock routine to measure how long the program takes to run and to determine whether my optimisation steps are really worth it. As an example of what I'm doing here's a test-code I wrote:

!--------------------------------------------------------------------------------
CALL SYSTEM_CLOCK(COUNT_RATE=clock_rate) ! Find the clock rate
CALL SYSTEM_CLOCK(COUNT=clock_start) ! Start timing

!Give the processor something to do:
do I=1,50000
WRITE(*,*) I
enddo

CALL SYSTEM_CLOCK(COUNT=clock_end) ! Stop timing
elapsed_time=float(clock_end-clock_start)/FLOAT(clock_rate)
WRITE(*,*)'Program ends, elapsed time=',abs(elapsed_time),'s'
WRITE(*,*) clock_rate, clock_end, clock_start
!--------------------------------------------------------------------------------

And compiled it using two different fortran compilers. Absoft MP Pro and FTN95. The results I got were as follows:

ABSOFT: clock_rate=1000000, clock_end=2000000, clock_start=0, elapsed time=2.000s
FTN95 :clock_rate=10000, clock_end=797406370, clock_start=0, elapsed time=797483176s

The absoft compiler gave the correct time (measured with a stopwatch); the run-time was around 2s for both cases. I'm wondering why this should be the case. Could someone please help me resolve this issue - we have FTN95 in my office so it'd make life much easier if i could use this exclusively.

My rig is a HP Zd8181EA with pentium 4 processor (3.2Ghz) and 1 Gig ram. I'm not sure if this will change anything though as the same rig was used for both codes.

I'd be hugely grateful if someone could lend a hand with this irritating issue.
Cheers,
Bren
!--------------------------------------------------------------------------------

[PaulLaidler]

Bren

Your code runs OK for me. The value of clock_start that you give is incorrect. When I run the code the value is of the same magnitude as clock_end.
You must have declared these as INTEGER otherwise the code would not compile so I cannot see what has gone wrong.
I get the same results for both Win32 and .NET (about 2.5 seconds or so).

Paul

[Anonymous]

Paul,

Thanks for checking that for me. I don't know why I'm getting a different time calculated on this machine. Could it be anything to do with the pentium 4 processor or a compiler setting I don't know about?

I did declare the clock variables as integers - the full code is

-------------------------------------------------------------------------
program test_time
IMPLICIT NONE
INTEGER :: I, COUNT, COUNT_RATE, test
INTEGER :: clock_end, clock_start, clock_rate
REAL :: elapsed_time

CALL SYSTEM_CLOCK(COUNT_RATE=clock_rate) ! Find the clock rate
CALL SYSTEM_CLOCK(COUNT=clock_start) ! Start timing

!Give the processor something to do:
do I=1,50000
WRITE(*,*) I
enddo

CALL SYSTEM_CLOCK(COUNT=clock_end) ! Stop timing
elapsed_time=float(clock_end-clock_start)/FLOAT(clock_rate)
WRITE(*,*)
WRITE(*,*)'Program ends, elapsed time=',abs(elapsed_time),'s'
WRITE(*,*) clock_rate, clock_end, clock_start
READ(*,*)

end program test_time
------------------------------------------------------------

I don't understand why compiling this code with the FTN95 should give me an incorrect result. If the results for the time are incorrect then I'm worried that other errors may have slipped into some of my numerical results (

Thanks for taking a look at the problem.
Bren

[Anonymous]

Hello again Paul,
I just realised that there was a mistake in my original post. The Clock values for the program run in FTN95 were incorrectly stated. The actual values for clock_end and clock_start are of similar magnitude as you suggested. This still doesn't explain why my code gives incorrect timing values though - this is frustrating.....

Cheers,
Bren

[PaulLaidler]

Bren

Integer overflow is a possibility though it does not explain your problem.
INTEGER(KIND=4) seems to work OK.
Lack of precision with the REAL calculation is also a possibility.
Try REAL(KIND=2).

Paul

[Anonymous]

Paul

I've just tried the program again but changed the real variables to double precision - there's no change. As usual the absoft compiler produced an exe file that gave the correct time. In the code I'm working with at the moment (not the time_test one!) the Absoft compiler also produces an executable which runs faster. Is it possible that the FTN95 compiler hasn't installed properly onto my machine?

Bren

[Anonymous]

Paul

I've finally fixed this frustrating problem. I tried changing the configuration so that the final executable file was "Release .Net" type as opposed to "Release Win32". The system_clock option was then able to calculate the correct time. I can't think why this would be the case; the only thing I can think of is that the win32 option somehow interacts with windows files. I have heard that the pentium 4 processors can sometimes appear as 2 linked processors in winXP so this may be responsible for the miscalculation of clockspeeds etc.

Thanks for your replies to my query - it's good to know there are still some people out there that will help a stranger.

Much appreciated,
Bren

[JohnCampbell]

I've just discovered a problem with system_clock using a new 3.19ghz HP Compaq with Salford Ver 3.80, windows XP
The clock counter is going backwards ??
successive calls to System_clock give : 1766249598, 1766249596, 1766249592, ..90, ..89, ..87 etc
I used the sample program for this problem report and included a call to system_clock in the do loop.
high_res_clock@ appears not to work also.

Any ideas Paul ?

Regards John Campbell

[PaulLaidler]

None at all.
It looks like we need to look at the inner workings of this routine for modern fast processors.
Someone may wish to do some trials using direct calls to Windows API functions.

[Anonymous]

If you wish to send me the API calls then I can certainly test them.
An advantage of high_res_clock has always been it's high speed, so if the problem could be corrected that would be an advantage. At present I use cpu_clock@, which is working correctly, for processor time and QueryPerformanceCounter for elapsed time.

[PaulLaidler]

John

SYSTEM_CLOCK and HIGH_RES_CLOCK@ both use QueryPerformanceCounter and QueryPerformanceFrequency.

Here is some simple Fortran code that uses these API calls. The results you get will help us to locate the problem.


integer,parameter::lKind = selected_int_kind(1
integer(lKind):: time1, time2, freq
logical ok

STDCALL QUERYPERFORMANCECOUNTER 'QueryPerformanceCounter' (REF):LOGICAL
STDCALL QUERYPERFORMANCEFREQUENCY 'QueryPerformanceFrequency' (REF):LOGICAL

ok=QueryPerformanceCounter(time1)
ok=QueryPerformanceFrequency(freq)

do i = 1,5000000
k = 1
enddo

ok=QueryPerformanceCounter(time2)

print*, float(time2-time1)*1000/freq !The number of milliseconds for the process to complete.
end

[JohnCampbell]

Paul,

I have tested SYSTEM_CLOCK on both my 1.9 ghz notebook and my 3.2 ghz desktop.

The notenook gives a frequency of 3,579,545 but the desktop gives a frequency of (about) 3,190,000,000, which is the ghz speed.
The test results I previously sent from the desktop, when freq is copied to an I*4 integer, are consistent with the negative and 3 times clocking speed that I got when testing on the desktop, using timing.f95. This makes me think that there is some I*4 arithmetic somewhere in the SYSTEM_CLOCK or high_res_clock@ calculation.
For the notebook, the frequency is not the processor ghz but a much smaller number and I*4 roundoff is less likely to occur. There is definately a limit to how long SYSTEM_CLOCK can be used to time a process.

Thanks again for your contributions on this problem.

Regards John

[PaulLaidler]

John

If there is a problem with system_clock etc then it is not due to using I*4 in the internal code.
If you would run the sample code that I posted, the results you get will help me to identify the problem.
That is, does the sample code provide a satisfactory timing process?

Regards

Paul

[JohnCampbell]

Paul,

I hope you received the results of the timing tests I sent previously.
I am puzzled by the time it takes to call SYSTEM_CLOCK and also QueryPerformanceCounter. There is also considerable variation in the time to process the call between different processors.
I also note that real*10 cpu_clock@ is still the fastest and most accurate routine to return the cpu performance count. Is it safe to assume that this routine does use the rated processor hz, as processor speeds increase ?

Thanks again for your valued support. It is much appreciated.

regards John

[PaulLaidler]

John

FTN95 calculates the values in CPU_TIME by calling the Windows API function GetProcessTimes.
Internally the integers are *8 and the reals are single, double or extended precision depending on the call.

With this information you may be able to get the answer to your question by looking up the Microsoft documentation for GetProcessTimes.