strange behaviour of dsecnd()

[vkv_kettle]

Hello!

I got strange results by using descnd() for time measurements. Namely, there is a simple code attached to this post with this problem.

Briefly, this code (I hope there are enough comments) measures time intervals for two blocks of simple operations carried out with some dynamic arrays.

To run this example I:

1)call "c:\\program files\\intel\\compiler\\c++\\10.0.025\\ia32\\bin\\iclvars.bat" ia32

call "c:\\program files\\intel\\compiler\\11.0\\066\\fortran\\mkl\\tools\\environment\\mklvars32.bat"

2) then compile it

icl mkl_intel_c.lib mkl_sequential.lib mkl_core.lib bugtest.cpp -o bugtest_dsecnd.exe

3) run the executable file (bugtest_dsecnd.exe)

The only output file contains values of time measurements for two blocks of operations.

The problem is that some time intervals between consecutive calls of dsecnd() routine are negative (array time2 for time_measurements which corresponds to the second column in the output file).

Moreover, I faced this problem with a more complicated code and resulting time measurements had horrible dispersion and negative numbers (and even the average time for one step of the main loop happened to be negative).

I'm not sure that this code reproduces such results always. But I get negative numbers (6 among 100 iterations=100 lines of numbers in the output file (main loop in the code has N=100 iterations)) steady.

OS: Microsoft Windows XP Professional 2002 Service Pack 3.

Version of Intel MKL: 10.1

Processor: AMD Athlon 64 X2 Dual Core Processor 6000+ 3.00GHz

I think this problem is connected with AMD Processor & Intel MKL combination. Because with all the same running this program on the computer with Intel processor, I got nice results with no negative numbers and small spread in values.

I would be very grateful to get any useful comments about the problem I mentioned above.

vkv_kettle

[Gennady_F_Intel]

Please checked the problem with the latest MKL 10.3 update 6 available now ( You can try the evaluation version just for checking the problem's behaivior on your side). I checked and didn't reproduce the problem.

--Gennady

[vkv_kettle]

Do you have any suggestions why the attached code can generate negative time intervals? (And I hope you've read the first post attentively and tried this code on AMD Dual Core processor)

Sorry for my question but do I have to download full trial version of MKL and install it (is installation over the current version enabled?) just to try this test and then roll back to my previous version. It seems to take a piece of time if there is no other way.

---vkv_kettle

[mecej4]

This is hardly an MKL issue, since the only routine that you pull in from MKL is the non-standard timing function DSECND. This function was a common vendor extension provided with Fortran compilers.

The closest that I can come to your hardware and compiler versions is the following:

AMD 64-X2 4200+, Windows XP SP3, Windows XP X64 SP1.

Intel Compiler ICC 12.1, IA32; Microsoft C 15.0 X86
MKL 10.2.5, IA32; MKL 10.3.6

With none of the compilers and MKL versions listed above did I see any negative values.

By asking for a combination of an older generation processor, an older OS and older compiler and MKL versions, you greatly reduced the probability of people who would be able to match your setup.

[Gennady_F_Intel]

confirmation -I can see the similar results onAMD Athlon 64 X2 Dual Core Processor 5600+

64 bit code only. We will investigate the problem.

--Gennady

[barragan_villanueva_]

Hi,

MKL dsecnd() function is implemented over hardware Time Stamp Counter register via RDTSC instuction
whichused with serialized instructions

mov eax, 00h; cpuid
to get current CPU time counter.
Negative values are possible if different CPUs have started differently or theirtime stamp countersare not synchronized.

[Julia_S_Intel1]

Negative values appear hereas TSCs give different values on different CPUs.If to add the code belowin the begining of your code, dsecnd()will be run on the same CPU and negative values will dissapear.

DWORD_PTR mask = 1;// CPU #0
mkl_set_num_threads(1); // force MKL init
SetThreadAffinityMask(GetCurrentThread(),mask);

[vkv_kettle]

Quoting Julia Sukharina (Intel)

Negative values appear hereas TSCs give different values on different CPUs.If to add the code belowin the begining of your code, dsecnd()will be run on the same CPU and negative values will dissapear.

DWORD_PTR mask = 1;// CPU #0
mkl_set_num_threads(1); // force MKL init
SetThreadAffinityMask(GetCurrentThread(),mask);

Thank you very much for your attention to my problem. With your help this error seems to be fixed in my case. (or it just doesn't reproduce itself now:)

P.S.

Correct me if i am wrong - this error can appear with any type of multicore processors, Intel or Amd or smth else?

And one more question - I've read something like the function SetThreadAffinityMask can be in some cases ignored by compilers, am I right?

---vkv_kettle

[TimP]

For multiple CPUs on a single motherboard, the BIOS or OS is responsible for resetting the TSC counters at boot, to bring them closely together.
In my experience, they have always agreed within a fraction of a microsecond on Intel products, as for several years these counters have been tied to the buss clock, so should not drift apart.
Even so, measures are recommended to assure that you don't compare TSC counters among CPUs (by using the same hardware thread when measuring time intervals). Thanks for bringing this up and to the MKL support people for explaining a method for dealing with the issue.

[barragan_villanueva_]

Quoting vkv_kettle

And one more question - I've read something like the function SetThreadAffinityMask can be in some cases ignored by compilers, am I right?

No. Maybe youheard about some libraries/tools which sometimes reset affinity mask.
Also please be informed about the folowing:
"Setting an affinity mask for a process or thread can result in threads receiving less processor time, as the system is restricted from running the threads on certain processors. In most cases, it is better to let the system select an available processor."