C99 and GMP tuning
dclarke at blastwave.org
Tue Apr 10 02:40:40 UTC 2018
On 09/04/18 05:30 PM, Vincent Lefevre wrote:
> On 2018-04-09 22:14:50 +0200, Hans Åberg wrote:
>> This page  says that POSIX clock_gettime  with clock id
>> CLOCK_PROCESS_CPUTIME_ID offers better resolution than clock.
> Under Linux, clock is based on clock_gettime with
> CLOCK_PROCESS_CPUTIME_ID, but the result is in microseconds
> only because CLOCKS_PER_SEC is 1000000 as required by XSI.
> The practical accuracy of clock_gettime with
> CLOCK_PROCESS_CPUTIME_ID seems about 0.4 microsecond
> (at least on my machine), so that there isn't much difference
> between both.
> The advantage of getrusage is that you can choose to consider
> the user time only.
> I'm attaching a program to compare clock related functions
> I wrote some time ago.
I'll take a look at this tomorrow with my sparc systems becasue Solaris
has a call called gethrtime for "get high resolution time" which also
returns nanosecs but promises :
The gethrtime() function returns the current high-resolution
real time. Time is expressed as nanoseconds since some arbi-
trary time in the past; it is not correlated in any way to
the time of day, and thus is not subject to resetting or
drifting by way of adjtime(2) or settimeofday(3C). The hi-
res timer is ideally suited to performance measurement
tasks, where cheap, accurate interval timing is required.
The gethrvtime() function returns the current high-
resolution LWP virtual time, expressed as total nanoseconds
of execution time.
The gethrtime() and gethrvtime() functions both return an
hrtime_t, which is a 64-bit (long long) signed integer.
So I can use that wrapped around some other calls just to get a feel for
the time being used.
Although the units of hi-res time are always the same
(nanoseconds), the actual resolution is hardware dependent.
Hi-res time is guaranteed to be monotonic (it won't go back-
ward, it won't periodically wrap) and linear (it won't occa-
sionally speed up or slow down for adjustment, like the time
of day can), but not necessarily unique: two sufficiently
proximate calls may return the same value.
I have used it in the past and this seems like a good time to roll it
out and see what data it may expose about other calls. Not portable at
More information about the gmp-discuss