time_t question.

[Longfellow]

Question from a C duffer par excellance, who has occasionally written
some useful C code and knows enough about C to get some idea of the
enormity of the amount he does not know.

Interesting and long thread about Nilges and the Sieve of Eratosthenes,
and I, as I suppose most did, compiled both Nilges' and Heathfield's
code (the former with some finagling, of course). In general, I
duplicated the values in Heathfield's table of run times, but I couldn't
figure out how he got values in thousandths of a second.

I looked at time.h in K&R2 and got the definitions of clock_t and time_t
values. Heathfield's usage seemed reasonably expectable of returning
time values of that precision; ie, there was no statement that time_t
only returned time to the nearest second. So I changed the fprintf from
%.0f t0 %.3f, but all I got was zeros to three places, indicating
precision only to the nearest second, IIUC.

clock()/CLOCKS_PER_SEC is defined as returning time since the start of
execution, so I substituted it for the "difftime(end, start). I got a
value to the required precision, but it didn't match Heathfield's
results and it did not change with a change in the range of the sieve.
I concluded that I was misunderstanding the K&R2 definition. I even
engaged in some desultory substitutions of clock_t for time_t with and
without various inline type assignments, and got no results as I
expected, but I figured I'd blindly do a little due diligence in case I
could stumble across something.

How did Heathfield get the degree of precision in his tables? What am I
missing here?

Thanks for reading,

Longfellow

 

[Morris Dovey]

Longfellow (in (e-mail address removed)) said:

| Question from a C duffer par excellance, who has occasionally
| written some useful C code and knows enough about C to get some
| idea of the enormity of the amount he does not know.
|
| Interesting and long thread about Nilges and the Sieve of
| Eratosthenes, and I, as I suppose most did, compiled both Nilges'
| and Heathfield's code (the former with some finagling, of course).
| In general, I duplicated the values in Heathfield's table of run
| times, but I couldn't figure out how he got values in thousandths
| of a second.
|
| I looked at time.h in K&R2 and got the definitions of clock_t and
| time_t values. Heathfield's usage seemed reasonably expectable of
| returning time values of that precision; ie, there was no statement
| that time_t only returned time to the nearest second. So I changed
| the fprintf from %.0f t0 %.3f, but all I got was zeros to three
| places, indicating precision only to the nearest second, IIUC.
|
| clock()/CLOCKS_PER_SEC is defined as returning time since the start
| of execution, so I substituted it for the "difftime(end, start). I
| got a value to the required precision, but it didn't match
| Heathfield's results and it did not change with a change in the
| range of the sieve. I concluded that I was misunderstanding the
| K&R2 definition. I even engaged in some desultory substitutions of
| clock_t for time_t with and without various inline type
| assignments, and got no results as I expected, but I figured I'd
| blindly do a little due diligence in case I could stumble across
| something.
|
| How did Heathfield get the degree of precision in his tables? What
| am I missing here?

The easy way is to run the timed code multiple times (say 1000 for
sake of argument) in a single run - and then divide by that number of
repetitions.

 

[Gordon Burditt]

Interesting and long thread about Nilges and the Sieve of Eratosthenes,

and I, as I suppose most did, compiled both Nilges' and Heathfield's
code (the former with some finagling, of course). In general, I
duplicated the values in Heathfield's table of run times, but I couldn't
figure out how he got values in thousandths of a second.

I looked at time.h in K&R2 and got the definitions of clock_t and time_t
values. Heathfield's usage seemed reasonably expectable of returning
time values of that precision; ie, there was no statement that time_t
only returned time to the nearest second. So I changed the fprintf from
%.0f t0 %.3f, but all I got was zeros to three places, indicating
precision only to the nearest second, IIUC.

time() and clock() measure very different things with differing
resolution. clock() is more like a football game clock. Relative
to time() it starts and stops a lot.

Make sure that clock()/CLOCKS_PER_SEC does not do integer division
(losing any fractions). Perhaps clock()/(double) CLOCKS_PER_SEC
would be better on implementations such as FreeBSD where clock_t
is an integer type and CLOCKS_PER_SEC is #define'd as an integer
value (128 for FreeBSD 6.0).

difftime() is for time_t, not clock_t.

Gordon L. Burditt

 

[Richard Heathfield]

Longfellow said:

In general, I
duplicated the values in Heathfield's table of run times, but I couldn't
figure out how he got values in thousandths of a second.

How did Heathfield get the degree of precision in his tables? What am I
missing here?

That, Longfellow, was simplicity itself, I assure you. Here's a demo:

me@here:~/scratch/sieve> time ./sieve 1 31415926 > /dev/null
Total primes found: 1940015
Approximate execution time (seconds): 8

real 0m8.174s
user 0m8.120s
sys 0m0.010s



Yes, my C code had time() calls in it, but only because I was, in essence,
duplicating the functionality of another program which also had them. I
didn't actually use the values given because I knew that, in my case, they
were meaningless.

Actually, I was surprised to see time() calls in Nilges's original code. I
would have thought date() would have been more appropriate. ;-)

 

[Longfellow]

Longfellow said:




That, Longfellow, was simplicity itself, I assure you. Here's a demo:

me@here:~/scratch/sieve> time ./sieve 1 31415926 > /dev/null
Total primes found: 1940015
Approximate execution time (seconds): 8

real 0m8.174s
user 0m8.120s
sys 0m0.010s



Yes, my C code had time() calls in it, but only because I was, in essence,
duplicating the functionality of another program which also had them. I
didn't actually use the values given because I knew that, in my case, they
were meaningless.

Actually, I was surprised to see time() calls in Nilges's original code. I
would have thought date() would have been more appropriate. ;-)

Oops, 'man time'. Do recall having run across it, but don't recall ever
having used it, actually.

Running Nilges' code was like compiling a very large application that
bails out just before the end. On an old 386 machine.

btw, appreciate the lucidity of your writing on the C language.

Thanks for the timely response!

Longfellow