446,413 Members | 996 Online
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
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'scode (the former with some finagling, of course). In general, Iduplicated the values in Heathfield's table of run times, but I couldn'tfigure 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_tvalues. Heathfield's usage seemed reasonably expectable of returningtime values of that precision; ie, there was no statement that time_tonly returned time to the nearest second. So I changed the fprintf from%.0f t0 %.3f, but all I got was zeros to three places, indicatingprecision 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: 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/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 general, Iduplicated the values in Heathfield's table of run times, but I couldn'tfigure out how he got values in thousandths of a second. >>How did Heathfield get the degree of precision in his tables? What am Imissing 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.