The "resolution" of the time function is not the problem.
If it were, just running the test longer would fix it.

The problem is that, from the very beginning of UNIX days,
kernel processes are NOT interruptible. Therefore any
user process may take any amount of real-time. And,
the attempts measure and make available cpu-time are
affected in the same way. There is no predictable time
lapse in gaining access to the kernel time data.

The answer is the make multiple runs of the same (fairly
long) test and then choose a suitable "average." It can
be argued that the "best" choice is the minimum reported value.
This one will have been least affected by delays during
kernel processes. Keep in mind that read/write to I/O
devices are kernel processes so quite a few seconds can elapse
before anything else can happen to timing calls or anything
else.

This choice was made by the original Bell Labs UNIX folks
when they thought that what they were doing was building a
convenient, single-user, report writing system. The rest is
history...

Even running Linux as a virtual system under a controlling
system which does not use uninterruptible calls does not
fix the problem because the Linux call still has to block until
its results are returned. System efficiency is improved by
this choice, but it does not change the behavior of client
systems.

So, any of the timing routines can be chosen.

Oh.  I think I was confused by the summary of this report to think that we were talking about using clock_gettime to provide cputime.

In any case, if there isn't a gnulib module for a portability function, then I think we should try to add the wrapper to gnulib.  If that can't be done, I'd still like to isolate the portability decisions/wrappers in liboctave's wrapper directory.

I think these functions are provided by gnulib, so I would prefer to use those and be able to just assume that they exist.  I do understand that it would require some wrapper functions for portability, but I would prefer to use those as we do for other functions instead of adding #ifdefs in liboctave or libinterp.

Continuing from this post:

https://savannah.gnu.org/bugs/?52809#comment22

I've implemented the example loops with cputime and tic/toc as functions:

function tdiff=bm_for_loop()
a = 1; b = 1; t0=cputime; for i=1:1000; for j=1:1000; a = a + b + 123.0; end;
end; t1=cputime; tdiff = t1 - t0

function t1=bm_for_loop2()
a = 1; b = 1; t0=tic; for i=1:1000; for j=1:1000; a = a + b + 123.0; end; end;
t1=toc(t0); t1

As results, I'm seeing:

octave:9> tl=zeros(20,1); for i=1:20; tl(i) = bm_for_loop; end;
tdiff =  2.7720
tdiff =  2.8040
tdiff =  2.7960
tdiff =  2.8000
tdiff =  2.8000
tdiff =  2.8000
tdiff =  2.8000
tdiff =  2.8000
tdiff =  2.8160
tdiff =  2.8000
tdiff =  2.8000
tdiff =  2.7960
tdiff =  2.7960
tdiff =  2.8000
tdiff =  2.8000
tdiff =  2.8040
tdiff =  2.7960
tdiff =  2.8160
tdiff =  2.7960
tdiff =  2.8000
octave:10> tl2=zeros(20,1); for i=1:20; tl2(i) = bm_for_loop2; end;
t1 =  2.7467
t1 =  2.8181
t1 =  2.8147
t1 =  2.8200
t1 =  2.8073
t1 =  2.8180
t1 =  2.8186
t1 =  2.8184
t1 =  2.8127
t1 =  2.8237
t1 =  2.8149
t1 =  2.8078
t1 =  2.8130
t1 =  2.8135
t1 =  2.8145
t1 =  2.8168
t1 =  2.8243
t1 =  2.8114
t1 =  2.8069
t1 =  2.8138
octave:11> mean(tl)
ans =  2.7996
octave:12> std(tl)
ans =  0.0085987
octave:13> mean(tl2)
ans =  2.8118
octave:14> std(tl2)
ans =  0.016044
octave:15> mean(tl2) - mean(tl)
ans =  0.012160

I don't think I can conclude there is a statistically significant difference from that, given there could be slightly different CPU usage between invocations.

I do believe though that there could be a difference in the above link, statistically speaking, i.e.,

octave:1> bm_for_loop
ans =  4.6840
octave:2> bm_for_loop
ans =  4.6640
octave:3> bm_for_loop
ans =  4.6240
octave:4> bm_for_loop2
t1 =  4.4830
octave:5> bm_for_loop2
t1 =  4.5830
octave:6> bm_for_loop2
t1 =  4.4962

I wonder if the issue there is that, in fact, the test is physically taking less time to operate than what cputime() reports because cputime() might include a combination of CPU usage from more than one processor core.  That is, perhaps some small aspect of this test can be shifted to a second CPU in a multi-threaded environment.