Problem with clock() (time.h)

[duragezic]

(1) I need to time the execution of some procedure that uses multiple threads to do the execution. See the code attached.

The problem is that start and finish both receive the value 0 from clock(). I made some defines large so that the execution would take a 3-4 seconds (in case the timing wasn't very precise), yet those variables always get the value 0 returned from clock(). Thus, the time elapsed is always 0.

I'm wondering if the fact that I spawn threads from the main process has anything to do with clock() returning zero? I don't see why it should, but this is my first time programming with threads.

(2) A misc question I have is regarding struct declarations in C++. See the attached code. Does using typedef in the second version mean that I can use

stuff someStuff;

instead of

struct stuff someStuff;

? Or is there other differences between the two?

(3) edit: Also, one other question. I attached the code (the delete part maybe not be the correct syntax, but you get the idea). Both creating the 2D threads array on the stack and the heap seem to work the same. I was thinking maybe it should go on the heap since each thread has their own stack, but share the heap. But I guess each thread doesn't actually use the threads[][] itself... only the process creating them uses it to keep track of them.

Thanks!

 

[EagleKeeper]

Looking at the MSDN documentaitno for clock()
double duration = (double)(finish - start) / CLOCKS_PER_SEC;

stuff someStuff;

instead of

struct stuff someStuff;

? Or is there other differences between the two?

In the first, stuff must have been defined prior to use.

struct stuff
{
...
};
....
stuff someStuff;

 

[Spydermag68]

 

[duragezic]

I updated the OP with a new question as well.

EagleKeeper:
I tried that just now. Same result (though the original way I calculated time elapsed seemed odd with the casts, but I got it from the net). Regardless of how I calculation the duration, the start and finish clock_t variables are always zero, so the expression evaluates to 0. I figure the clock_t variable would be overloaded to display its double value when using << on it (similar to pid_t, which isn't an integer variable, but can be displayed as one with %d).

spyder:
I'm not sure that just getting the tm_sec would be precise enough. If I don't artificially make values large so that the computation takes a long time, it actually only takes a second or two. Thus I might get a value of 0 or 1 seconds elapsed, which would be too large of a unit to accurately compare the timing of the execution under different methods. I suppose that means I should time the execution on clock ticks and not divide by CLOCKS_PER_SEC.

 

[Yomicron]

clock() measures execution time. I suspect that it works on a per-thread basis, so your code would only be measuring the execution time of the main thread. If all you main thread does is spawn other threads and wait for them to complete, then its actual execution time may not be long enough to see the value from clock() change.

 

[Matthias99]

Yah... I'm not so sure if clock() plays nice with multithreaded programs on all platforms.
If you're using POSIX threading, you might try times():

http://www.gnu.org/software/libc/manual...ode/Processor-Time.html#Processor-Time

which I think works better for that.

You can also use platform-specific methods of getting at CPU timers, etc. directly (like QueryPerformanceCounter() in the Windows API). This is the best way to measure the actual amount of elapsed time during small blocks of code (that, or use a profiler, but that can't always get you things like how long different parts of a function call take.)

But it looks like that may not be a perfect solution, at least on Windows XP: http://support.microsoft.com/?id=896256 . There is a fix, though. I don't know if that fix has been put out through Windows Update (I know a couple of AMD dual-core fixes were, but I'm not sure if that one was.)

Both creating the 2D threads array on the stack and the heap seem to work the same. I was thinking maybe it should go on the heap since each thread has their own stack, but share the heap. But I guess each thread doesn't actually use the threads[][] itself... only the process creating them uses it to keep track of them.

That array is used to store state information about the threads (whether they are still running, are blocked, etc.) Any additional memory needed by the threads themselves (such as their stacks) will probably be allocated on the heap of the process. In any case, the OS and/or thread manager does that sort of stuff for you, so you don't need to worry about it.

 

[duragezic]

Thanks guys. I'll check into tms since I am using Pthreads. This program is for a linux platform, so I can also check out what specific time functions are available for it.

So my hunch on using a bunch of threads and the clock() always zero issue may've been right. One thing that is odd is that I attempt to get the 'start' value from clock() before spawning threads, then I print it right way with cerr, and even then it is always zero! From my understanding, clock() should return the number of clock ticks since the program started. There is some argument checking code in main() and variable declarations before ever getting to the function that gets the start time then spawns threads and so on. Even though a CPU can execute those minor things in a very short period of a time, you would think it would at least be some clock ticks (10, 20+?). I mean, if you looked at the assembly code, it would have to be maybe 10-15 instructions from the start of the program until I get to the point I get the start time. Oh well, I'll try something else that you suggested, Matthias99.


Matthias99: re: array on stack or heap:
Ok, that makes more sense now. And since then I've read a few sections from the book basically stating that.

So in this case there is no functional difference whether I declare the array on the stack or dynamically allocate it on the heap? I'm not sure if we ever covered that exactly in my C++ class. I mean I've tried both ways and the program/threads execute the same. Doing it on the heap requires a bit more code and then I have to free the memory before exiting. So would I be correct in saying that it would make more sense to declare it on the stack as whatever reasons to declare stuff on the heap would not apply here?

Thanks! Not sure where I'd go without you guys! Not looking for anyone to do my homework or anything, but it's certainly nice to know my programming assignments inside and out (and get As). I can help other people much better as well, which helps "solidfy" the knowledge.

 

[Matthias99]

Originally posted by: duragezic
Thanks guys. I'll check into tms since I am using Pthreads. This program is for a linux platform, so I can also check out what specific time functions are available for it.

So my hunch on using a bunch of threads and the clock() always zero issue may've been right. One thing that is odd is that I attempt to get the 'start' value from clock() before spawning threads, then I print it right way with cerr, and even then it is always zero! From my understanding, clock() should return the number of clock ticks since the program started. There is some argument checking code in main() and variable declarations before ever getting to the function that gets the start time then spawns threads and so on. Even though a CPU can execute those minor things in a very short period of a time, you would think it would at least be some clock ticks (10, 20+?). I mean, if you looked at the assembly code, it would have to be maybe 10-15 instructions from the start of the program until I get to the point I get the start time. Oh well, I'll try something else that you suggested, Matthias99.

I don't believe clock() is really that accurate; it may only get updated occasionally (such as when your process actually gets swapped in/out). Even if CLOCKS_PER_SEC is very large, you are not guaranteed that clock() will return a different value every (1/CLOCKS_PER_SEC) seconds. A typical value might be 1000000 (making the 'clock cycles' counter a microsecond counter), but it might only be updated once a millisecond or something like that.

If you want down-to-the-nanosecond timing information, you need to get direct access to the hardware counters on the CPU.

So in this case there is no functional difference whether I declare the array on the stack or dynamically allocate it on the heap? I'm not sure if we ever covered that exactly in my C++ class. I mean I've tried both ways and the program/threads execute the same. Doing it on the heap requires a bit more code and then I have to free the memory before exiting. So would I be correct in saying that it would make more sense to declare it on the stack as whatever reasons to declare stuff on the heap would not apply here?

I'm not sure it ever makes a whole lot of difference (at least on a PC with a relatively uniform memory architecture). That structure is (I'm pretty sure) only going to be used by the scheduler and some of the thread management functions.

Plus, the distinction between 'stack' and 'heap' is just one of where exactly the buffer is located in memory. The pthread functions are just going to take a pointer into that buffer, and they don't behave any differently if the pointer is into the stack versus the heap. The OS and/or threading library is going to decide where the thread's stack goes (probably on the heap of your process), and any memory dynamically allocated by the thread will go on the heap.

 

[duragezic]

I'm trying out the GNU C times function and tms structure but it's not quite right either.

The output from the four variables I print to stderr are:

start = 1779245604
tmsStart->tms_utime = 0
finish = 1779245605
tmsFinish->tms_utime = 0


I believe start and finish are the current calendar time. So those do me no good since as you can see, only 1 second elapsed (1 second to spawn over a 100 threads to do a computation). I tried all of the tms structure's members listed (stime, cutime, etc), but all of them are 0 as well.

Damn. I just want to get the number of clock ticks elapsed! Nothing I've tried has worked.

 

[LintMan]

I think times() and maybe clock() are giving you CPU time, ie the amount of processor time used, which can be very different than than amount of real time elapsed, which is why you're getting the 0's.

Solaris has a system call called gethrtime(), which returns a high resolution timer value, but I don't think Linux has an equivalent. But I found this page:
IO Port HOWTO which if you scroll down to section 4.2 talks about how gettimeofday is usually accurate to 1usec, and they also provide a C/ASM snippet to read the system clock (ticks since bootup).

Probably gettimeofday() is your best bet.

 

[Aikouka]

The descriptions of clock() that I read mention that it logs the number of ticks since the program began. If you think multi-threading is causing an issue, try removing the threads and replacing them with something more archaic (try a loop) and see what happens then.