timing-quotient test occasionally fails on armhf

[d-torrance]

From an armhf PPA build in Ubuntu 20.10:

testing: timing-quotient.m2
      -- version 1.8: 17.5 seconds
      -- after fix: .166 seconds
      assert Equation(numgens tim#1, 33)

ii9 : assert BinaryOperation {symbol <, tim#0, .5 * standardSecond}
timing-quotient.m2:217:1:(3):[4]: error: assertion failed:
1.13816<1.04997 is false
Command exited with non-zero status 1
4.63user 0.48system 0:04.90elapsed 104%CPU (0avgtext+0avgdata 91624maxresident)k
0inputs+48outputs (0major+21455minor)pagefaults 0swaps
timing-quotient.errors:0: error output left here for the errors above:
make[5]: *** [../Makefile.test:67: timing-quotient.out] Error 1

This test was the reason behind the recent assert changes, and I finally got to see it in action!

We're just missing the upper bound by less than a tenth of a second.

[DanGrayson]

Very cool.

[d-torrance]

I ran some experiments on the three architectures I have access to. For both of the timing comparisons in this test, I ran the computation 100 times on amd64 (my local system), armhf (Raspberry Pi), and arm64 (Linaro Developer Cloud) and recorded the timing results as a fraction of standardSecond. Here were the results:

architecture	quotient test (mean)	quotient test (sd)	factor test (mean)	factor test (sd)
amd64	.177641	.00637202	.00590899	.000181648
armhf	.244146	.0101577	.0153686	.000113174
arm64	.334095	.012216	.0126624	.0020093

So the current upper bounds of 0.5 and 0.05, respectively, for the two tests seem totally reasonable based on these results. But every machine's different, I suppose, and the upper bound is too low for Ubuntu's ARM PPA build machines, at least for the first test.

For the two times I've seen this test fail since the assert changes (the one mentioned above and this one from last night), the fraction of standardSecond necessary was 0.542 and 0.568, respectively. So I suppose bumping the first upper bound up to .6 * standardSecond might fix this.

[d-torrance]

Had an interesting result in an amd64 Ubuntu 21.04 PPA build. standardSecond was surprisingly short:

testing: timing-quotient.m2
      -- occasionally caused build failures, see:
      -- https://github.com/Macaulay2/M2/issues/1804
      -- https://github.com/Macaulay2/M2/pull/1811
      -- https://github.com/Macaulay2/M2/pull/1957
      assert BinaryOperation {symbol <, tim#0, standardSecond}
timing-quotient.m2:224:1:(3):[4]: error: assertion failed:
.307505<.000004779 is false

[DanGrayson]

Maybe the loop in "spin" got optimized away, and we have to put it into a separate file and build it with -O0.

spin(e:Expr):Expr := (
     when e is x:ZZcell do (
	  if isInt(x.v) then (
	       n := toInt(x.v);
	       for i from 1 to n do for j from 1 to 290000 do Ccode(void,"do_nothing()");
	       nullE)
	  else WrongArgSmallInteger())
     else WrongArgZZ());
setupfun("spin",spin);	 -- used for benchmarking when debugging, e.g., threads