As you may know, clock() and gettimeofday() are not really the good ones to use to check the timing.
Details of those timing functions are explained in one of our artilces for the IPP library which is located at
Snippets from the artilce below.
clock(): The granularity of clock() function is dependent on implementation by various compiler vendors. The C standard does not say anything about the granularity of clock() - a compiler can have it check time once a second and increment the variable by CLOCKS_PER_SEC. This means it is possible that, depending on different compiler implementation, you can get zero, CLOCKS_PER_SEC, CLOCKS_PER_SEC * 2 and so on, never getting any intermediate value. Don't use clock() if you need high granularity.
gettimeofday(): It returns time in milliseconds or the wall clock time. The precision of gettimeofday is also very bad, for example, for a 3 GHz machine that means precision == 3 million of cpu clocks only. If your application does only calculations, clock() and gettimeofday() would be fairly close. Any time, if the application starts waiting for something (for e.g: DISK I/O), clock() will lag behind compared to the gettimeofday(). clock() can also go faster than gettimeofday() if you have multiple threads running in the same process.
We recommend to use the MKL timing functions. Details of those functions are in "Support Functions" section of the reference manual. Online version can be found in
We have investigated the described situation and found the root cause. The reason of the issue is in mkl function dsecnd() which is used inside PARDISO for time measurement. The function dsecnd() takes approximately 0.5 sec for initialization in the first call; and this amount of time is not counted at all. So first run of PARDISO takes 0.5 sec more time than following calls.
We can propose the following workaround for the issue:
in the beginning of the program please callDSECND for dry run to complete initialization process.