[Octave-bug-tracker] [bug #34234] two tests fail in speed.m (MinGW)

[Rik]

Follow-up Comment #8, bug #34234 (project octave):

I know what the problem is.  The question now is what the best fix for the
issue is.

According to the documentation for speed, the vector return value N is


The values N for which the expression was calculated AND the
          execution time was greater than zero.


The key is that the execution time needs to be greater than zero.  On
operating systems with low resolution timers the elapsed time reported will
often be zero when it was really just too small to measure.

Tatsuro provided me the execution data from his test and the measured times
were


T_f1 =

 Columns 1 through 12:

   9.9993e-04   9.9993e-04   9.9993e-04   9.9993e-04   9.9993e-04   1.9999e-03
  2.0001e-03   3.0000e-03   3.0000e-03   3.9999e-03   3.9999e-03   4.9999e-03

 Column 13:

   6.0000e-03


On my Linux machine, the times were


T_f1 =

 Columns 1 through 12:

   9.2387e-04   1.1330e-03   9.8085e-04   8.1801e-04   1.7231e-03   1.2410e-03
  1.3001e-03   1.6189e-03   1.8952e-03   2.1369e-03   2.6469e-03   3.1180e-03

 Columns 13 through 15:

   3.4690e-03   4.1111e-03   4.8628e-03


As you can see, the MinGW timer is accurate to 1 millisecond.  The Linux timer
seems to have sub-millisecond accuracy (although it's still probably accurate
to only 0.2 millisecond)

Another problem with the demo is that even on a machine with good resolution
timers, if the machine is exceedingly quick then the elapsed time will be
zero.

So, the first question is whether there is a better resolution timer available
on MinGW and Cygwin and how we can access it.  The current speed.m uses
time().  We could try using tic() and toc() but they might still rely
internally on the time() system call.

Tatsuro, could you try the following code and see what it reports?


tic; usleep (10); toc
tic; usleep (100); toc
tic; usleep (1000); toc


The other possibility is to change the speed test functions to perform more
work in each loop and guarantee that there will be a meaningful delay to
measure.  Another choice would be to validate the test less harshly.  Instead
of returning exactly 15 time points it should return some number of elapsed
times in the range 5-15.  This might be easier and more forgiving since Linux
is reporting 15 values, MinGW is reporting 13 values, and Cygwin is reporting
11 values.  


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?34234>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/