clock() always returns 0?

[tymk]

Running 64-bit Fedora 8 on HP laptop with AMD Turion 64bit/dual core, developing in Eclipse, compiling with g++. The clock(); function always returns 0. Any ideas why this is so? I have had no problems using the rest of the ctime library.

#include <ctime>
using std::clock;
#include <iostream>
using std::cout;

int main()
{
	for (int i=0; i < 50; i++)
	{
		cout << clock() << '\n';
	}
    return 0;
}

Thanks.

[Salem]

Perhaps because only 50 times round the loop is nothing to a modern 64-bit machine.

Add some calls to sleep, or some other substantial amount of work, and then it'll tick nicely.

[tymk]

Thanks. I thought of that, so I ran something like:

...
clock_t b,e
int a
b = clock();
cout << clock() << '\n';
cin a;
cout << clock() << '\n';
e = clock();
cout << (e-b)/(1.0*CLOCKS_PER_SEC) <<'\n';

I ran several times -- waiting from a few seconds to several minutes to enter my input and get the second clock and all outputs are always 0. cout << CLOCKS_PER_SEC; returns 1000000, so clock(); should return at least that number after 1 second, right?

[Dave Sinkula]

Thanks. I thought of that, so I ran something like:

Try not to paraphrase code. Work with the real deal.

[vijayan121]

the C library clock() does not give the wall clock:

the clock() function determines the amount of processor time used since the invocation of the calling process, measured in CLOCKS_PER_SECs of a second.

just sleeping or waiting for input will work for time() (which gives the wall time), not for clock() ; no processor time is used by the process while it is in a wait state.

[Salem]

Something which might actually take a while if you type in a couple of thousand for each value.

cin >> a >> b;
double r = 0;
for ( int i = 0 ; i < a ; i++ ) {
  for ( int j = 0 ; j < b ; j++ ) {
    r = r + i * j;
  }
}
cout << r;

This simple looking function will consume the universe if you let it.

[tymk]

Yeah, I finally opened my eyes and stopped being lazy about it. I ran this exact code: (;) Dave...):

#include <ctime>
using std::clock;
#include <iostream>
using std::cout;

int main()
{
	clock_t b,e,c,n;
	
	b = clock();
	c = -1;
	
	for (int i=0; i < 50000; i++)
	{
		n = clock();
		if (n != c)
		{
			c = n;
			cout << "i = " << i << "; clock = " << c << '\n';
		}
	}
	
	e = clock();
	cout << (e-b)/(1.0*CLOCKS_PER_SEC) << '\n';
    
	return 0;
}

I ran it many times and the results were pretty consistent, one iteration (exactly):

i = 0; clock = 0
i = 7830; clock = 10000
i = 15705; clock = 20000
i = 19647; clock = 30000
i = 30599; clock = 40000
i = 32576; clock = 50000
i = 37824; clock = 60000
i = 48335; clock = 70000
0.07

So now that I can admit that the problem was with me, not clock(), I find it interesting that the resolution implied by CLOCKS_PER_SEC is 1/1000000 second, but my actual results show 1/100 second. Not important for my task at hand, though. Thanks for taking the time to teach me a few things.

[vijayan121]

> I find it interesting that the resolution implied by CLOCKS_PER_SEC is 1/1000000 second,
> but my actual results show 1/100 second.
how typical of linsux. appearances are more important than technical accuracy.
the reason for this dishonesty:

STANDARDS
     The clock() function conforms to ISO/IEC 9899:1990 (``ISO C90'').  How-
     ever, Version 2 of the Single UNIX Specification (``SUSv2'') requires
     CLOCKS_PER_SEC to be defined as one million.  FreeBSD does not conform to
     this requirement; changing the value would introduce binary incompatibil-
     ity and one million is still inadequate on modern processors.

- FreeBSD man pages (FreeBSD reports 128 as the value of CLOCKS_PER_SEC)

however, your os would have a variety of clocks/timers, many with much higher resolution.
see: http://www.freebsdmanpage.com/man/clocks-7.html

[tymk]

Thanks for the info. That is unfortunate, but the Linux (note spelling, you had a typo) OS I am using is free, so I can't complain too much about it. And like I said, it is adequate for what I am doing.

[Salem]

> how typical of linsux. appearances are more important than technical accuracy.
> the reason for this dishonesty:
And if they didn't conform to published specifications, you'd find something else to complain about like the impossibility of writing any kind of portable software.

But updating clock() every 100th of a second is surely an implementation choice of any given kernel compilation. If you know what you're doing, and your hardware is capable of supporting it, then higher accuracy clocks should be possible.

Separating resolution from accuracy allows a great deal of freedom in creating a conforming implementation.