Different Answers on Different Machines

[mattintelnetfort]

Hi

We're upgrading to the 11.0 compiler and noticed that when we run some code on the machine that it was built on, we get timer values we expect (returned in seconds). When we run the same executable on another machine, the timer values come back in milliseconds. Does anyone have an explanation? Here's the code:

USE DFPORT
REAL*4 ET(2)

UCP=ETIME(ET)
CPU=ET(1)

We'd originally wondered whether it's a DLL (e.g., libifportmd, libifcoremd, libmmd), but don't see our exe referencing these DLLs through depends.exe.

Our exe is statically linked; are there any DLLs that need to be installed on the problem machine in order to support consistent results?

Thanks

[TimP]

I don't have a direct answer to this question, but I don't see a good reason why you would use etime rather than the standard Fortran cpu_time here. etime did vary in usage between brands of compilers, which is one reason for the introduction of cpu_time over a decade ago.

[mattintelnetfort]

Quoting - tim18

I don't have a direct answer to this question, but I don't see a good reason why you would use etime rather than the standard Fortran cpu_time here. etime did vary in usage between brands of compilers, which is one reason for the introduction of cpu_time over a decade ago.

Changing to cpu_time seemed to work, thanks; that is we now get consistent answers regardless of machine. However, I'm still a bit leary about our process given the strange behavior with ETime on different machines.

Again thanks, and if there are any more thoughts on explaining Etime behavior, I'd appreciate them.

[Steven_L_Intel1]

If your application is statically linked, there are no DLL dependencies.

However, I am aware that the implementation of ETIME was recently changed, supposedly to be more consistent with what other implementations do. Personally, I find the "new" definition just plain weird.

"Now for the single processor they return CPU-time; for multiple (or multicore) processors they return the wall-clock time and the system-time is always 0."

So the difference between the systems may be that one is a single-processor and the other a multicore or multiprocessor.

I will say, though, that routines such as ETIME do not have a standard definition and that you are much better off to use a standard-defined routine such as CPU_TIME. Even with that, though, you can get into endless arguments about what to return in a multithreaded application.

[mattintelnetfort]

Quoting - Steve Lionel (Intel)

If your application is statically linked, there are no DLL dependencies.

However, I am aware that the implementation of ETIME was recently changed, supposedly to be more consistent with what other implementations do. Personally, I find the "new" definition just plain weird.

"Now for the single processor they return CPU-time; for multiple (or multicore) processors they return the wall-clock time and the system-time is always 0."

So the difference between the systems may be that one is a single-processor and the other a multicore or multiprocessor.

I will say, though, that routines such as ETIME do not have a standard definition and that you are much better off to use a standard-defined routine such as CPU_TIME. Even with that, though, you can get into endless arguments about what to return in a multithreaded application.

Thank you, I believe that explains it. Based on your explanation, we've checked the machines in the test and the pattern seems to follow that single processor machines (one in our test) returns in seconds, while multiprocessor machines (two in our test) return milliseconds.

We'll use cpu_time as recommended, and stay away from ETIME. Again thanks!

[Steven_L_Intel1]

The time unit ought not to be different - that's just wrong! I'll test this and report it as a bug if I can reproduce it.

[Steven_L_Intel1]

I did reproduce it and have reported it as issue DPD200118871. On a single-processor system, the unit is seconds but on a multiprocessor/multicore, it's 1000 seconds ("kilo-seconds") I sort-of understand the change from CPU to wall-clock time depending on processor - this is what Sun Fortran does - but the change in units to "kilo-seconds", as documented, I can't find a precedent for. I have recommended that the unit be seconds no matter what.