0

I'm having issues with execution times of C OpenMP scripts.

Timing within the script is done on a block of code using the gettimeofday() function:

gettimeofday(&tim, NULL);
double t1=tim.tv_sec+(tim.tv_usec/1000000.0);

.. Timed Code Here

gettimeofday(&tim, NULL);
double t2=tim.tv_sec+(tim.tv_usec/1000000.0);
printf("%.6lf seconds elapsed\n", t2-t1);

However when I run the scripts successively the time for each execution increases:

terminal screenshot

The script has not been edited since yesterday where I did not have this issue. Also, I found that when leaving some time (say 10-20 seconds) then rerunning the program execution the time starts to decrease.

My only guess is that it is something to to with the process itself. I am using GCC version 4.8.2 to compile on Linux Mint 17 Using XFCE (gcc 4.8.2-19ubuntu1):

gcc bluromp.c -fopenmp -o bluromp.out

Any ideas?

EDIT: Added clock() from time.h for testing:

start_t = clock();

.. Timed Code Here

total_t = (double)(end_t - start_t) / CLOCKS_PER_SEC;
printf("Time.h clock result: %ld\n", total_t);

Results:

terminal screenshot 2

Clock is also increasing although workload is in program is the same (as said previously, if I wait ~20 seconds execution time is less

EDIT 2:

When running on another machine the results for successive runs of the program are correct, so the problem lies on my system somewhere.

EDIT 3:

Using Sync does not help, this morning my timings seem to jump rather than simply increase, I think it must be a cache or memory issue somewhere:

enter image description here

EDIT 4:

Used vmstat to get memory/cpu info:

enter image description here

Jamie Stuart Robin Parsons
  • 1,132
  • 4
  • 20
  • 36
  • How is this problem related to bash? -- I only see C code here – Jdamian Nov 05 '14 at 18:17
  • Sorry I meant to tag terminal not bash, edited. – Jamie Stuart Robin Parsons Nov 05 '14 at 18:20
  • 1
    What about it has to do with the timed code! Is the code doing the exact same thing always, 100% sure? Otherwise, what other things are you running on you machine? – meaning-matters Nov 05 '14 at 18:24
  • @meaning-matters - I'm not sure what you mean. The code is timed from a [start]-[end] basis declared on each run, so successive runs should not alter this. – Jamie Stuart Robin Parsons Nov 05 '14 at 18:25
  • 1
    Have you tried executing the code on a different machine? This would give some hints whether the system or the code is producing the problem. – Turing85 Nov 05 '14 at 18:43
  • 1
    @Turing85 - Running on a different machine gives me the correct set of results (hence no time increase per run). So the issue is to do with my machine, however I don't know how to fix it – Jamie Stuart Robin Parsons Nov 05 '14 at 18:57
  • Give more code context. For example all but the OpenMP part. And also details about what & how you calculate and how you input/output data (from files perhaps?). – meaning-matters Nov 05 '14 at 20:21
  • The timed section of the code is simply a triple-nested loop with a controlled amount of iterations. A file in read and a new one created during the execution of the file, but outside of the timed section. – Jamie Stuart Robin Parsons Nov 06 '14 at 06:43
  • Seems like memory issue to me. Probably the I/O leaves a lot of dirty pages in the filesystem cache and those are flushed on consecutive program runs in order to free physical memory frames for use in the program, slowing things down. You can use tools like `vmstat` to monitor the system behaviour while your program executes. It also explains why your program runs normally if you wait 20 seconds - the cache gets flushed every now and then automatically. Try running `sync` every time before you start the program, e.g. `sync && ./blurOMP.out`. – Hristo Iliev Nov 06 '14 at 07:48
  • Edited question. Sync does not seem to help and vmstat seems to look normal (what do you think). Results this morning seem more jumpy than yesterday – Jamie Stuart Robin Parsons Nov 06 '14 at 08:41
  • what kind of machine are we talking about? Could the problems come from hardware-limitations (e.g. not enough RAM) as @Hristo Iliev suggested? – Turing85 Nov 06 '14 at 08:52
  • What happens if you run it like `OMP_PROC_BIND=true ./blurOMP.out`? – Hristo Iliev Nov 06 '14 at 09:03
  • @Turing85 - Machine has 6GB memory, the script process only uses about 5MB and as a whole the system never goes above 2GB – Jamie Stuart Robin Parsons Nov 06 '14 at 09:12
  • @HristoIliev - Using that did not have an effect on the time – Jamie Stuart Robin Parsons Nov 06 '14 at 09:12
  • Download and install [likwid](https://code.google.com/p/likwid/) and run the code via [likwid-perfctr](https://code.google.com/p/likwid/wiki/LikwidPerfCtr) and examine the `MEM` group of counters. – Hristo Iliev Nov 06 '14 at 09:43
  • Installed, can you give me an example code run for a dual core cpu (4 threads). Tried: likwid-perfctr -c 1 2 -g MEM ./blurOMP.out but getting errors – Jamie Stuart Robin Parsons Nov 06 '14 at 10:01
  • `likwid-perfctr -C 0-3 -g MEM ./blurOMP.out` You should also try to compile your code without OpenMP and see if the serial version exhibits the same problem. – Hristo Iliev Nov 06 '14 at 12:17

0 Answers0