By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,413 Members | 996 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,413 IT Pros & Developers. It's quick & easy.

time_t question.

P: n/a
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

Jul 2 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Longfellow (in 12*************@corp.supernews.com) 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.

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto
Jul 2 '06 #2

P: n/a
>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
Jul 2 '06 #3

P: n/a
Longfellow said:

<snip>
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.
<snip>
>
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/sievetime ./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. ;-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jul 2 '06 #4

P: n/a
On 2006-07-02, Richard Heathfield <in*****@invalid.invalidwrote:
Longfellow said:

<snip>
>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.
<snip>
>>
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/sievetime ./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

Jul 2 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.