Re: function ETIME in v11.*

teosim · ‎12-10-2009

Hi,

It is aboutsomehowstrange behaviour infunction ETIME(if not a bug), which is part of the portability library libifport.a.
The function works fine for up to about 2000 seconds and thenturns negative. Basically this isthe result of TARRAY(1) getting negative. The second TARRAY(2), which is supposed to be the system time never getsa value.
Thiscan be observed in ifort v11.0.83 and v11.1.059
A simple code is listed below. Sure you will have to wait ~35mins to see it negative. However TARRAY(2),might be observed rather quickly.
A work around would be to link the code withan older libifport.a fex from v9.1.032 works fine.

The question is: Is there any documented changes in LIBIFPORT and possibly in the rules to use it after v9 or v10? I believe v10 is also OK.

Thank you
Teo

Note. Compile with -O0, otherwise make somehow the machine busy.

PROGRAM TIMER
REAL(4) :: ECPU, TARRAY(2)
REAL M
NN = 50
DO I=1, 800
DO J= 1, NN
DO K1= 1, NN
DO K2= 1, NN
DO K3= 1, NN
DO K4= 1, NN
M = J**0.5 + 1
ENDDO
ENDDO
ENDDO
ENDDO
ENDDO
! ---------------------
ECPU = ETIME(TARRAY)
! ---------------------
PRINT*, 'CPU=', ECPU, TARRAY(1:2)
ENDDO
STOP
END

teosim · ‎12-10-2009

The above anomaly can be observed only on ia32 linux.
intel@64 seems to be OK.

/Teo

Ron_Green · ‎12-10-2009

Quoting - teosim

The above anomaly can be observed only on ia32 linux.
intel@64 seems to be OK.

/Teo

strange - I'm on an IA32 system using 11.1.059 and don't see what you are:

[rwgreen@spd16 70514]$ ./repro-etime
CPU= 6.980000 6.980000 0.0000000E+00
CPU= 13.98000 13.97000 9.9999998E-03

CPU= 5586.480 5584.210 2.270000
CPU= 5593.490 5591.210 2.280000
[rwgreen@spd16 70514]$ uname -a
Linux spd16 2.6.9-11.EL #1 Fri May 20 18:17:57 EDT 2005 i686 i686 i386 GNU/Linux

This is on an old Pentium 4, Willamette processor. What processor do you have?
$ more /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 0
model name : Intel Pentium 4 CPU 1500MHz

teosim · ‎12-11-2009

uname -a
Linux teobox 2.6.11.4-20a-smp #1 SMP Wed Mar 23 21:52:37 UTC 2005 i686 i686 i386 GNU/Linux

more /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel Pentium 4 CPU 3.00GHz
....
processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel Pentium 4 CPU 3.00GHz

It is definitely not a new machine. It runs SuSE 9.3.
Initially I also thought that it might be an installation issue,
but it is reproducible on another(newer) machineas well. Please see the test below.

Thank you.
/Teo

more /etc/SuSE-release
SUSE Linux Enterprise Server 10 (x86_64)
VERSION = 10
PATCHLEVEL = 2

>uname -a
Linux listsp14 2.6.16.60-0.42.7-smp #1 SMP Tue Nov 3 11:20:42 UTC 2009 x86_64 x86_64 x86_64 GNU/Linux

>more /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel Xeon CPU X5450 @ 3.00GHz
....

ifort -V
Intel Fortran Compiler Professional for applications running on IA-32, Version 11.1 Build 20091012 Package ID: l_cprof_p_11.1.059

The command line is identical for IA64 and INTEL64:
>ifort -c -O0 timerx.f90 -o timerx.o
>ifort -v -o timerx.exe -static timerx.o

** IA32-version**
CPU= 2.060000 2.060000 0.0000000E+00
CPU= 4.000000 4.000000 0.0000000E+00
CPU= 5.940000 5.940000 0.0000000E+00
CPU= 8.000000 8.000000 0.0000000E+00
CPU= 9.940000 9.940000 0.0000000E+00
CPU= 11.88000 11.88000 0.0000000E+00
......
CPU= 2140.340 2140.340 0.0000000E+00
CPU= 2142.280 2142.280 0.0000000E+00
CPU= 2144.220 2144.220 0.0000000E+00
CPU= 2146.160 2146.160 0.0000000E+00
CPU= -2146.867 -2146.867 0.0000000E+00
CPU= -2144.927 -2144.927 0.0000000E+00
CPU= -2142.977 -2142.977 0.0000000E+00
CPU= -2141.037 -2141.037 0.0000000E+00
CPU= -2139.097 -2139.097 0.0000000E+00
CPU= -2137.157 -2137.157 0.0000000E+00

**intel64-version**
CPU= 2.040000 2.040000 0.0000000E+00
CPU= 4.030000 4.030000 0.0000000E+00
CPU= 5.980000 5.980000 0.0000000E+00
CPU= 7.920000 7.920000 0.0000000E+00
CPU= 9.860000 9.860000 0.0000000E+00
CPU= 11.80000 11.80000 0.0000000E+00
......
CPU= 2139.250 2139.250 0.0000000E+00
CPU= 2141.200 2141.200 0.0000000E+00
CPU= 2143.140 2143.140 0.0000000E+00
CPU= 2145.090 2145.090 0.0000000E+00
CPU= 2147.030 2147.030 0.0000000E+00
CPU= 2148.970 2148.970 0.0000000E+00
CPU= 2150.910 2150.910 0.0000000E+00
CPU= 2152.850 2152.850 0.0000000E+00
CPU= 2154.800 2154.800 0.0000000E+00
CPU= 2156.740 2156.740 0.0000000E+00

Ron_Green · ‎12-14-2009

I'm still not seeing the same as you, and I did the compile and static link that you specified. However, I am on RedHat and not SLES 10. Let me try to find a SLES 10 system and try again.

Just to be sure: you are sourcing the compiler ifortvars script and NOT just setting PATH and LD_LIBRARY_PATH yourself, right?

source /opt/intel/Compiler/11.1/059/bin/ifortvars.sh ia32

CPU= 2628.630 2627.840 0.7900000
CPU= 2635.620 2634.830 0.7900000
CPU= 2642.610 2641.820 0.7900000
CPU= 2649.610 2648.810 0.8000000
CPU= 2656.600 2655.800 0.8000000
CPU= 2663.590 2662.790 0.8000000
CPU= 2670.580 2669.780 0.8000000
CPU= 2677.590 2676.780 0.8100000
CPU= 2684.590 2683.780 0.8100000
CPU= 2691.580 2690.770 0.8100000
CPU= 2698.570 2697.760 0.8100000
CPU= 2705.560 2704.750 0.8100000
CPU= 2712.560 2711.740 0.8200000
CPU= 2719.540 2718.720 0.8200000
CPU= 2726.530 2725.710 0.8200000
CPU= 2733.530 2732.710 0.8200000
CPU= 2740.530 2739.700 0.8300000
CPU= 2747.510 2746.680 0.8300000
CPU= 2754.500 2753.670 0.8300000
CPU= 2761.510 2760.670 0.8400000
CPU= 2768.500 2767.660 0.8400000
CPU= 2775.480 2774.640 0.8400000

Ron_Green · ‎12-14-2009

One other question while I wait for my SLES 10.2 system test:

Do you have ONLY the 11.1.059 compiler on the system, or do you have older 10.x or 11.0 compilers on there as well?

thanks

ron

teosim · ‎12-14-2009

Quoting - Ronald W. Green (Intel)

One other question while I wait for my SLES 10.2 system test:

Do you have ONLY the 11.1.059 compiler on the system, or do you have older 10.x or 11.0 compilers on there as well?

thanks

ron

There is no other Intel compiler on that SLES 10-SP2, machine.

On the 32-bit, (SLES v9.3),v9.1.032 and v11.0.82 are also there.

The environment is always setby sourcing ifortvars.csh

Thank you for your time.
/Teo

Ron_Green · ‎12-14-2009

I don't have a SLES 10.2 system for ia32. I have an Intel 64 system with SLES 10.2 and I tried the 32bit compiler. No luck in reproducing this.

Another thing to try: on that last ifort command, add option -dryrun so I can see all the libraries, defines, etc. that the compiler is using.

Also, what GCC version is on the system?

ron

teosim · ‎12-15-2009

Quoting - Ronald W. Green (Intel)

I don't have a SLES 10.2 system for ia32. I have an Intel 64 system with SLES 10.2 and I tried the 32bit compiler. No luck in reproducing this.

Another thing to try: on that last ifort command, add option -dryrun so I can see all the libraries, defines, etc. that the compiler is using.

Also, what GCC version is on the system?

ron

This is exactly what I did too forthe testing.I made a clean installationon Intel64 SLES 10.2 and built the sample with ia32 and Intel64: ia32- fails for me; intel64 - works.
Attached file contains the requested information: -dryrun.
gcc version 4.1.2 20070115 (SUSE Linux).

I am sorry for the confusion. I am running out useful ideas.
May be I should try to find a RedHat node and make new test.

Thank you.
/Teo

teosim · ‎12-15-2009

I am sorry. The ia32-test failed on the RedHat node listed belowas well.
The only common feature I can think of is that it isalso amulti-core CPU.
/Teo

more /etc/redhat-release
Red Hat Enterprise Linux ES release 4 (Nahant Update 8)

more /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel Core2 Duo CPU P9500 @ 2.53GHz
stepping : 6
cpu MHz : 800.000

gcc version 3.4.6 20060404 (Red Hat 3.4.6-11)

Ron_Green · ‎12-15-2009

I was finally able to reproduce what you are seeing.

I reproduced on a SLES10 Intel64 server using Xeon 5500 series processors (Nehalem), identical SLES10 and gcc to yours AND i used c-shell instead of bash, 11.1.059 ia32 compiler.

Thanks for the -dryrun output: that allowed me to confirm that I had absolutely identical gcc libs, paths, etc.

I will try to isolate this now, but as you know, there is a SLOW turn-around time on each experiment.

ron

Ron_Green · ‎12-16-2009

bug report posted: DPD200148646

Two possible workarounds:

use Intel 64 compiler

(this may work) substitute with CPU_TIME(), which is a Fortran 95 intrinsic function. I need to test this, though, since it may use the same underlying implementation as etime.

ron

teosim · ‎12-16-2009

Thanks a lot for your help resolving this.
Unfortunately, the replacement of ETIME is at the moment out of question. It is part of an application, started 25 years ago, and which is supposed to run on all kinds of Unix and Windows platforms. Intel64, both Linux and Windows,are required as well, but not all users are readyto adopt the 64-bit.
I agree, that in therms of the Fortran standard, CPU_TIME is now a better option, but for the time beingI would rather step back and useIF v9.1untila patch becomes available.

Thank you again for the great support.
/Teo

TimP · ‎12-17-2009

Among the reasons for introducing CPU_TIME in Fortran 15 years ago was the different ways in which ETIME was used on various platforms, by various compilers. No compiler issued during that period should have a problem with CPU_TIME nearly as great as the problems with ETIME.