topic One time measurement is not in Intel® oneAPI Math Kernel Library

Getting different time measurement while runs a same code

prash_r_ — Fri, 01 Aug 2014 05:54:33 GMT

hi.,

as i'm running a example code in intel mkl directory /opt/intel/composer_xe_2013_sp1.0.080/mkl/examples/spblasc with the following time function:

#include<mkl.h>

double time_st = dsecnd();

// function call

double time_end = dsecnd();
double time_avg = (time_end - time_st)/LOOP_COUNT;

printf("Average time: %e secs n", time_avg);

getting different results all the time.

can I get to know why this is happinning. and how to overcome from this problem.

thanku

regrads:

prash r.

Are suggest me if there is

prash_r_ — Fri, 01 Aug 2014 07:12:09 GMT

Are suggest me if there is any other way to measure the time.

Hi Prash,

Ying_H_Intel — Fri, 01 Aug 2014 08:54:46 GMT

Hi Prash,

What is your problem size and loop account , and what is your OS and hardware type?

The article may be help :

https://software.intel.com/en-us/articles/a-simple-example-to-measure-the-performance-of-an-intel-mkl-function. ;

As currently OS have mutil-tasks runing almost at all times and out of order execution within CPU. So many factors contribute to the performance of an Intel MKL subroutine, such as problem size, memory size, parallelism, states of caches, branch prediction logic, OS resource scheduled and so on. that is why we usually use statistical number as performance measure and described a tips in the article : ignore the time required by the first Intel MKL call.

Best Regards,

Ying

TimP — Fri, 01 Aug 2014 12:52:24 GMT

If running on multple cpu platform while excluding competing tasks, setting omp_proc_bind should help.

As @Ying H wrote in his

Bernard — Sun, 03 Aug 2014 14:14:55 GMT

As @Ying H wrote in his response there are a lot of factors which can contribute to variation in function timing between consecutive measurement and beetwen consecutive test runs.

For example main thread which is running the code of timed function between two runs of tests could have been swapped out by more priviledged thread for varying amount of time.

One time measurement is not

Yu__Tao — Mon, 04 Aug 2014 01:44:51 GMT

One time measurement is not meaningful. In this case, statistical number might help. For example, you can run a group of consecutive measurement, ignore the max number and min number, and calculate the standard deviation of this group of number. If the standard deviation is lower than a criteria, then take the average value of the numbers as the run time of the program.

Another thing you might need to consider is the busy level of the computer when you take the measurement. For the same program, when your computer is super busy on other tasks, the run time of this program may be much higher than when the computer is not busy. Then the question is how the compare the results of the two measurement. So you need a benchmark if you want to compare the results.

hi, thank you all for a

prash_r_ — Mon, 04 Aug 2014 05:25:55 GMT

hi, thank you all for a excellent explanation.

it there any effect on time if i clear the cache memory each time using

command: sync; echo 3 | sudo tee /proc/sys/vm/drop_caches ?

regards:

prash r.

@prash

Bernard — Mon, 04 Aug 2014 14:13:21 GMT

@prash

If you are on Windows you can increase thread executing priority to even Real-Time for the period of the timing. By doing this you can decrease the context switching frequency of your thread. This should help to achieve more accurate result of timing measurement.