clock()

I am measuring the time elapsed for a multi-threading program. I already used gettimeofday() and I want to try with clock() now. The problem is I don't get logical results
Effectively I do this on all threads:

Code:

---

pthread_barrier(...);
if (threadId == 0) s=clock();
//ALGORITHM
pthread_barrier(...);
if (threadId == 0) {
  f=clock();
  time = (double)(f - s) / CLOCKS_PER_SEC;
}

---

so the first thread calculates the time. Though the results are wrong. Am I missing something?

Perhaps you want f - s instead of s - f?

--
Mats

Quote:

---

Originally Posted by matsp

Perhaps you want f - s instead of s - f?

--
Mats

---

Yeah, miss typed. That is what I do. I generally get a smaller time with more threads. But, I get a bigger time if I use 4 threads for example than not using threads at all.

And how many processors do you have? If you have 4 cores, using four threads may actually be slower than using for example three threads - depends a lot on what the application does.

--
Mats

Quote:

---

Originally Posted by matsp

And how many processors do you have? If you have 4 cores, using four threads may actually be slower than using for example three threads - depends a lot on what the application does.

--
Mats

---

I have 8 cores. The application just does some calculations, multiplies one array with an other stores the result to a third, nothing else. With gettimeofday() it works fine

Are you using clock() per thread? Or subtracting from since when the application started?

Quote:

---

Originally Posted by man clock

In order to measure the time spent in a program, clock() should be called at the start of the program and its return value subtracted from the value returned by subsequent calls.

---

*could* have something to do with it.

[edit]
How do you know it's wrong?

And according to the POSIX documentation, time() and therefore gettimeofday() keep static data -- and are therefore not thread-safe. So it could have been wrong the first time around, now it's right...
[/edit]

How large is the array, and how are you walking it in the threads?

--
Mats

Well, generally only the first thread counts time, since it synchronizes with the rest with pthread_barrier(). So it will count the time from the start until every thread is finished. But that is the logic with the gettimeofday().
In any case, how should I measure time with clock()?

The array can be very large. Like 40M of elements. The array is just split in number of threads times. Each thread takes one piece.

Well, I know it is wrong because I measure the time with no threads and the time using multiple threads and the time with multiple threads is bigger. It can't be slower with multiple threads than with one thread since we are talking about a 8-core system. And in any case, the results with gettimeofday() make sense. Like it is faster with 8 threads than 7 threads, etc etc. The results with clock() make less sense.

Can you elaborate in the thread-safe thing?

I might be have a million of bugs, just want to make sure that my logic is correct

clock() in a Unix/Linux system actually returns the CPU time used, so if you are using 4 CPU's for one minute each, you should get 240 seconds. Try to make an experiment where you, instead of doing your math, do something like this:

Code:

---

time_t t1, t2;

t1 = time(NULL);
do
{
    t2 = time(NULL);
} while(difftime(t2, t1) < 10);

---

If you run n threads, you should see one of:
10 seconds
or
n * 10 seconds

My guess would be that it's n * 10 seconds.

For measuring multithreading, a combination of REAL (aka Wallclock) time (getcurrenttime()) and CPU time would be the best measure. The "best" solution is the one that uses the least amount of CPU time and the least REAL time (or the suitable compromise between those two if they do not "meet").

--
Mats

--
Mats

Did that. I get n* 10 seconds. What is the difference between getcurrenttime() and gettimeofday() ?

Also, according to this: http://www.opengroup.org/onlinepubs/...l#tag_02_09_01
gettimeofday() doesn't seem to be thread unsafe, besides every thread has its own variable and only one calls gettimeofday()

Oops my bad :)

Quote:

---

Originally Posted by C_ntua

Did that. I get n* 10 seconds. What is the difference between getcurrenttime() and gettimeofday() ?

---

Sorry, my memory having bit-errors (many bits wrong!) - I meant gettimeofday() - I think Windows uses something like "GetCurrentTime()" for the same thing, but don't rely on that.

--
Mats

I know that on my UNIX system at least (and hopefully on most of them) you can use the function gethrtime() to get really high resolution differences in timestamps.

QuantumPete

Quote:

---

Originally Posted by QuantumPete

I know that on my UNIX system at least (and hopefully on most of them) you can use the function gethrtime() to get really high resolution differences in timestamps.

QuantumPete

---

gettimeofday is pretty good - it gives a microsecond resolution (at least in theory!), and I think what the original post is asking for is so much about how to shorten the time, but rather how to make sure that the correct time sort of time value is measured/presented.

As discussed above, clock() for multiple threads will give a different result than timeofday, becaue n threads accumulate n * ticks per tick of time (if the OS is able to run all threads in parallel, which should be the case here).

--
Mats