Is time.h clock() broken on my hardware?

Question

I try to measure the clock cyles needed to execute a piece of code on the TMS32064x+ DSP that comes with the OMAP ZOOM 3430 MDK. I look at the "Programmer's Guide" of the DSP chip and it says that the DSP supports the clock() function.

What I do is really simple, I just do

start = clock();
for (i=0;i<100;i++){
    /* do something here */
}
stop = clock();
total = stop - start;

and then put the values of "start","stop" and "total" to a previously allocated shared memory with the ARM processor. Then I simply print it to the screen at the ARM side.

The problem is, in my first executes, I always get the same "total" value, and then in my next runs I always get 0! The "start" and "stop" values go along with the "total" value.

The strangest thing is that they seem to follow a bit pattern! I put the output below:

# ./sampleapp
Total = 63744
Start clock() value = 0x000000f9
Stop  clock() value = 0x0000f9f9
# ./sampleapp 
Total = 4177526784
Start clock() value = 0x00f9f9f9
Stop  clock() value = 0xf9f9f9f9
# ./sampleapp
Total clock cyles = 0
Start clock() value = 0xf9f9f9f9
Stop  clock() value = 0xf9f9f9f9

Apparantly, clock() is not functioning well, but I'm not sure if this is because of something I do wrong or because this type of thing is not supported with the hardware I have. Any ideas why this might be happening?

Snapdragon

Are you absolutely certain that clock is returning these values? You might just be looking at a problem with accessing the shared memory? – Rapping

To check this, I simply change one of the return values, say "start", to a predefined value or to the shared memory address' value and I get the correct thing on the screen. – Snapdragon

Does TI have any examples? I think with some of their other CODEC examples they were also calculating an elapsed time of execution. I don't remember if they used the clock() api. But it does seem to work in the decoder or encoder example code. – Levanter

I didn't come across any CODEC examples that use the DSP as well. If you know one, I appreciate a reference or link. – Snapdragon

is it possible to be a bug with the toolchain used? – Goodman

It may be! I'll ask TI about this. – Snapdragon

Is that exec() a "real", POSIX-style exec() call, or just notation? If it's an exec(), that will replace your process' image (assuming POSIX semantics), so the stop time will never be written. – Herring

I edited my post. With exec() I just wanted to imply there is a function called inside the loop; the function is actually irrelevant, and does only some math operations. – Snapdragon

Have you tried gettimeofday()? – Datura

Yes I have thought of it, but the DSP doesn't support it. I can't include sys/time.h . But as a work around I measure the run time of DSP from CPU with gettimeofday() and it works. The only thing is I have to subtract the overhead from messsaging manually. – Snapdragon

Do you have a link to the reference manual for the device you're using? – Deas

Answer 1

From reading the questions so far, I'd say the Original Poster has substantially more knowledge of this matter than the contributors so far, and that the suspicion that the clock() is broken (or not supported, and returns an undefined result) on the DSP seems quite likely.

Harts

I started to believe that this is the case too, so there is no need to leave this question as unanswered anymore. Thanks to you all. – Snapdragon

How humble of you Can Bal, that you have started to agree to believe that you have substantially more knowledge than the contributors, and selected as the answer the one stating that one. nice :) I agree that clock() is broken too, however, on OMAP. – Galcha

It seems you are not the only person having trouble with clock(). Perhaps the solutions provided here will be of help. #588807 – Radically

Answer 2

Curiously, Why do you require a previously allocated shared memory. Why don't you try with a normal stack variable? Is there anything that I am missing?

Inextricable

Yes, you're missing the fact that the code shown runs on one processor, the DSP, while the code that displays the results runs on another, the main ARM CPU. – Herring

Answer 3

Maybe you need to initialize the clock first.

Datura

As far as I know clock() takes the reference point as the initial call of the executable. I don't know how to initialize/reset its value manually. How do you do that? – Snapdragon

I've just reread the man pages, the standard gives no way to do such a thing. – Datura

Answer 4

How are you printing it out? maybe the issue is actually with displaying the result?

on most platforms clock_t is a long long. If you're using printf with %d you might get variable results which is what you're seeing.

Radically

I printed out sizeof(clock_t) and it is 4. It is defined as unsigned int. – Snapdragon

To persist on this vein, is your printing code proven good? Have you fed some values through the same kind of memory transfer / printout to check if they come accross correctly? – Nader

Answer 5

Assuming the start and end variable are of type 'clock_t', and your shared memory assumes the same on the other end's interpretation of the numbers passed, then your problem is not with the call to clock, and your handleing of the difference between the start end end times.

I believe your problem is in the shared memory between the two. Can you please post code to show how you're sharing memory between two separate processors?

Endor

I simply use the same method TI used through its dmmcopy sample. MPU side sample: gitorious.org/ti-dspbridge/userspace/blobs/master/source/… DSP sample: gitorious.org/ti-dspbridge/userspace/trees/master/source/… But I don't think the problem is with the shared memory since I can pass hard-coded values from DSP to CPU correctly instead of the start stop and total variables. – Snapdragon

Answer 6

Perhaps you could use some inline assembly to access the CPU's counter registers directly.

The TMS320C64x+ has a 64-bit timestamp register in TSCL, TSCH. The counter is not enabled on reset, you must first write to the register to start the counter (maybe this is the problem with clock?). Reading from the register is not quite trivial as each half must be read with a separate instruction (and you can get interrupts...).

Alkali

I didn't know this was an old question. This is what I get for not paying attention to timestamps! – Alkali