exp/orderbook: Use uint256s for pool calculations to improve performance

[2opremio]

Second attempt at #4104 by explicitly checking every possible overflow.

Before:

goos: darwin
goarch: amd64
pkg: github.com/stellar/go/exp/orderbook
cpu: Intel(R) Core(TM) i7-1068NG7 CPU @ 2.30GHz
BenchmarkVibrantPath
BenchmarkVibrantPath-8   	     100	  10375399 ns/op	 2758209 B/op	   64732 allocs/op
PASS

After:

goos: darwin
goarch: amd64
pkg: github.com/stellar/go/exp/orderbook
cpu: Intel(R) Core(TM) i7-1068NG7 CPU @ 2.30GHz
BenchmarkVibrantPath
BenchmarkVibrantPath-8   	     127	   9447364 ns/op	 2251733 B/op	   39260 allocs/op
PASS

[tamirms]

I tried comparing the uint128 calculations with the old code which uses math/big ones:

func TestCalculatePoolExpectations(t *testing.T) {
	for i := 0; i < 1000000; i++ {
		reserveA := xdr.Int64(rand.Int63())
		reserveB := xdr.Int64(rand.Int63())
		disbursed := xdr.Int64(rand.Int63())

		result, ok := calculatePoolExpectationBig(reserveA, reserveB, disbursed, 30)
		result1, ok1 := calculatePoolExpectation(reserveA, reserveB, disbursed, 30)
		if assert.Equal(t, ok, ok1) {
			assert.Equal(t, result, result1)
		}
	}
}

func TestCalculatePoolPayout(t *testing.T) {
	for i := 0; i < 1000000; i++ {
		reserveA := xdr.Int64(rand.Int63())
		reserveB := xdr.Int64(rand.Int63())
		received := xdr.Int64(rand.Int63())

		result, ok := calculatePoolPayoutBig(reserveA, reserveB, received, 30)
		result1, ok1 := calculatePoolPayout(reserveA, reserveB, received, 30)
		if assert.Equal(t, ok, ok1) {
			assert.Equal(t, result, result1)
		}
	}
}

Unfortunately there were a lot of cases where the results differed because there were cases where the numerator overflowed but after dividing by the denominator the result was in the bounds of an int64.

But I did find https://github.com/holiman/uint256 . The library is mostly compatible with the big.Int API so it was easy to swap in. When trying out the library I was able to get all the tests to pass and there was a decent performance improvement as well:

Before:

goos: darwin
goarch: amd64
pkg: github.com/stellar/go/exp/orderbook
cpu: Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
BenchmarkVibrantPath
BenchmarkVibrantPath-12    	     100	  11879873 ns/op	 2794719 B/op	   66595 allocs/op
PASS

After:

goos: darwin
goarch: amd64
pkg: github.com/stellar/go/exp/orderbook
cpu: Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
BenchmarkVibrantPath
BenchmarkVibrantPath-12    	     100	  10841301 ns/op	 2259508 B/op	   39745 allocs/op
PASS

[tamirms]

I have tested this by running through path finding requests on this branch and comparing the output with the result from the old code. Everything matches

[2opremio]

In some implementations, the reminder can be negative. But I think that only happens with negative integers. We should double-check to be sure since !IsZero() may not be semantically equivalent.

[2opremio]

It may be worth having a global var/constant for maxBips

[2opremio]

I don't get why the library doesn't expose DivMod() since that's how it implements Div() and Mod() internally:

https://github.com/holiman/uint256/blob/38e2c56bf6d3ee96b9d391351a612336b0b552a5/uint256.go#L485

[2opremio]

I created a ticket at holiman/uint256#103

[2opremio]

I wonder it it would be simpler and more performant to use Uint64WithOverflow()

[2opremio]

(we would still need to check that the result is <= than math.MaxInt64 though)

[2opremio]

@tamirms https://github.com/holiman/uint256 seems to have overflow/underflow-checking alternatives for all the operations.

I wonder if we should be using those, since, unlike https://lukechampine.com/uint128, https://github.com/holiman/uint256 doesn't seem to panic on overflows.

[2opremio]

I wonder if we should be using those

After reading the code, it seems that the overflow-checking may be considerably less performant. So we should make sure to double-check performance if/when doing it.