Add mutative in place operations to decimal types

[ValarDragon]

Summary

Currently all decimal operations allocate a new big int in memory. This is a very large performance hit for math-intensive operations. We should add operations such as add_in_place, mul_in_place, and quo_in_place to give developers the ability to get faster arithmetic should they need it.

This will keep the default code as immutable, so only developers who need this feature would themselves opt-into it.

Problem Definition

Allocating memory on each operation becomes an important speed pain-point for math intensive operations. This is 40% of the time for the Osmosis approximate power algorithm (Thanks to @Thunnini for finding this out)

osmosis-labs/osmosis#56

Proposal

Add add_in_place, mul_in_place, sub_in_place, neg_in_place and quo_in_place operations to sdk.Dec.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[ValarDragon]

@mconcat added this to osmosis' SDK fork here: osmosis-labs#10

Is this something SDK maintainers would like upstreamed? I don't know how it fits in with folks view of API safety, as this definitely does provide a footgun around mutability that may bite folks who aren't aware of it. (This is because copies of an Int still refer to the same pointer)

The performance improvement was quite substantial for us, as our computational load is really based on these math operations.

We are planning to do the same thing for Ints, and multiplications directly on the coins objects.

[aaronc]

Thanks @ValarDragon. This is something we'll need to think about. I did run into some pretty bad shared memory problems when trying to mutate decimal types in place using the apd library. This may be particular to the apd library, but it is something that does need to be done very carefully. The underlying issues were related to the array in the nat underneath big.Int I believe. At the same time, it does sound like a substantial speed up so it's worth exploring if it can be done safely.

I still would like us to replace the current sdk.Dec implementation with something more precise (#7773). I know you have your qualms about GDA/decimal128, but this so far that is the proposal with the most support. If we could get consensus about which direction to take for the future of sdk.Dec generally, I would be open to spending time on finding the most efficient implementation. (https://software.intel.com/content/www/us/en/develop/articles/intel-decimal-floating-point-math-library.html did well in my very rough benchmaks.)