This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2][BZ #12515] Improve precision of clock function
- From: Steven Munroe <munroesj at linux dot vnet dot ibm dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: munroesj at us dot ibm dot com, Siddhesh Poyarekar <siddhesh at redhat dot com>, libc-alpha at sourceware dot org
- Date: Tue, 21 May 2013 15:45:30 -0500
- Subject: Re: [PATCH v2][BZ #12515] Improve precision of clock function
- References: <20130521145611 dot GM8927 at spoyarek dot pnq dot redhat dot com> <20130521151839 dot GA18430 at domone dot kolej dot mff dot cuni dot cz> <20130521153442 dot GO8927 at spoyarek dot pnq dot redhat dot com> <519B9A09 dot 6030305 at cs dot ucla dot edu> <20130521161441 dot GQ8927 at spoyarek dot pnq dot redhat dot com> <1369155615 dot 30724 dot 111 dot camel at spokane1 dot rchland dot ibm dot com> <519BD3EF dot 80109 at cs dot ucla dot edu>
- Reply-to: munroesj at us dot ibm dot com
On Tue, 2013-05-21 at 13:07 -0700, Paul Eggert wrote:
> On 05/21/13 10:00, Steven Munroe wrote:
>
> >>> > > return (ts.tv_sec * CLOCKS_PER_SEC
> >>> > > + ts.tv_nsec / (1000000000 / CLOCKS_PER_SEC));
>
> > That will cause its own round error problems, so need to cast to long
> > long for multiply and divide to avoid this.
>
> I don't see any rounding error here -- can you give an example?
> Note that 1000000000 % CLOCKS_PER_SEC is guaranteed to be zero,
> which means it's safe to rewrite (x*1000000000)/CLOCKS_PER_SEC
> to x/(1000000000/CLOCKS_PER_SEC).
>
> If that isn't clear, perhaps we can prepend a line like the
> following, to make it clear:
>
> static_assert (1000000000 % CLOCKS_PER_SEC == 0);
>
That assume that __clock_gettime (CLOCK_REALTIME,) and CLOCKS_PER_SEC
are multiples of 10.
"Although the value of CLOCKS_PER_SEC is required to be 1 million on all
XSI-conformant systems, it may be variable on other systems, and it
should not be assumed that CLOCKS_PER_SEC is a compile-time constant."