apd: avoid function calls on hot paths

[nvanbenschoten]

This PR includes a pair of minor optimizations that avoid function calls on arithmetic hot paths.

short-circuit in Context.goError

This commit adds a fast-path for the common case in Context.goError that avoids the function call to Condition.GoError. Context.goError is inlined in callers, so this avoids any function call in the common case.

inline Context.round

This commit reworks the call to Context.round to allow for mid-stack function inlining. To do this, we remove the conditional call to one of two functions, which is considered too complex to inline.

---

name                 old time/op    new time/op    delta
GDA/minus-10           6.43µs ± 5%    6.11µs ± 5%  -5.11%  (p=0.000 n=25+25)
GDA/subtract-10        85.3µs ± 5%    81.2µs ± 2%  -4.81%  (p=0.000 n=25+19)
GDA/abs-10             4.76µs ± 5%    4.58µs ± 6%  -3.87%  (p=0.000 n=25+25)
GDA/tointegral-10      16.7µs ± 6%    16.1µs ± 5%  -3.77%  (p=0.000 n=25+20)
GDA/remainder-10       28.1µs ± 6%    27.1µs ± 6%  -3.70%  (p=0.000 n=24+25)
GDA/reduce-10          10.8µs ± 5%    10.5µs ± 6%  -3.19%  (p=0.000 n=25+25)
GDA/squareroot-10      12.6ms ± 5%    12.2ms ± 1%  -2.97%  (p=0.000 n=19+19)
GDA/divideint-10       13.9µs ± 5%    13.6µs ± 6%  -2.21%  (p=0.000 n=25+25)
GDA/tointegralx-10     17.0µs ± 5%    16.7µs ± 6%  -2.03%  (p=0.000 n=25+21)
GDA/powersqrt-10        194ms ± 4%     191ms ± 0%  -1.91%  (p=0.000 n=25+19)
GDA/quantize-10        71.2µs ± 5%    70.0µs ± 5%  -1.80%  (p=0.000 n=25+25)
GDA/plus-10            33.8µs ± 6%    33.2µs ± 6%  -1.59%  (p=0.000 n=22+20)
GDA/rounding-10         254µs ± 0%     250µs ± 0%  -1.56%  (p=0.000 n=19+19)
GDA/power-10            215ms ± 5%     212ms ± 0%  -1.30%  (p=0.000 n=24+19)
GDA/randoms-10         1.72ms ± 0%    1.70ms ± 0%  -0.93%  (p=0.000 n=19+19)
GDA/cuberoot-apd-10    1.80ms ± 4%    1.79ms ± 4%  -0.61%  (p=0.001 n=25+25)
GDA/log10-10            102ms ± 6%     102ms ± 0%  -0.43%  (p=0.024 n=20+19)
GDA/divide-10           234µs ± 5%     233µs ± 5%  -0.42%  (p=0.001 n=25+25)
GDA/ln-10              78.7ms ± 0%    78.5ms ± 0%  -0.24%  (p=0.000 n=19+19)
GDA/base-10             112µs ± 1%     112µs ± 2%    ~     (p=0.745 n=19+24)
GDA/compare-10         26.0µs ± 6%    26.1µs ± 6%    ~     (p=0.291 n=25+25)
GDA/comparetotal-10    24.3µs ± 6%    24.3µs ± 6%    ~     (p=0.473 n=25+25)
GDA/exp-10              117ms ± 3%     118ms ± 5%    ~     (p=0.352 n=19+25)
GDA/multiply-10        50.9µs ± 1%    51.1µs ± 5%    ~     (p=0.053 n=19+25)
GDA/add-10              556µs ± 1%     560µs ± 6%  +0.68%  (p=0.015 n=19+25)

note: the GDA/add test suite is heavily skewed towards extreme values and edge cases. GDA/subtract is a more representative test suite for common addition and subtraction operations.

[yuzefovich]

Reviewed 3 of 3 files at r1, 2 of 2 files at r2, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @nvanbenschoten)

---

-- commits, line 15 at r2:
nit: probably s/conditionally/conditional/.

---

round.go, line 70 at r2 (raw file):

	if disableIfPrecisionZero && c.Precision == 0 {
		// Rounding has been disabled.
		res |= d.setExponent(c, nd, res, int64(d.Exponent))

nit: why do we perform logical OR and not just return d.setExponent(c, nd, 0, int64(d.Exponent))?

[cockroach-teamcity]

This change is 

[nvanbenschoten]

TFTR!

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @yuzefovich)

---

-- commits, line 15 at r2:

Previously, yuzefovich (Yahor Yuzefovich) wrote…

nit: probably s/conditionally/conditional/.

Done.

---

round.go, line 70 at r2 (raw file):

Previously, yuzefovich (Yahor Yuzefovich) wrote…

nit: why do we perform logical OR and not just return d.setExponent(c, nd, 0, int64(d.Exponent))?

The idea was to mirror the structure of the other logic in this function more closely and not assume that res is 0 at this point in the code. But I agree that it's unnecessary and not worth the confusion. Changed.