C99 and GMP tuning

[Dennis Clarke]

On 09/04/18 05:30 PM, Vincent Lefevre wrote:
> On 2018-04-09 22:14:50 +0200, Hans Åberg wrote:
>> This page [1] says that POSIX clock_gettime [2] 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 :


DESCRIPTION
      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.

Also :

NOTES
      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 
all.  Sadly.

Dennis