chore: replace dashu math library with num-bigint in pallas-math

[whankinsiv]

This PR removes the dashu math library dependency and replaces it with num-bigint to standardize math operations across the codebase, improving consistency.

[AndrewWestberg]

Did you test the performance implications of this? Num-bigint was slow to validate blocks when I tested various math libraries back in the day.

[whankinsiv]

Did you test the performance implications of this? Num-bigint was slow to validate blocks when I tested various math libraries back in the day.

Did you test the performance implications of this? Num-bigint was slow to validate blocks when I tested various math libraries back in the day.

I will report back later today after I have the benchmarks completed.

[whankinsiv]

Did you test the performance implications of this? Num-bigint was slow to validate blocks when I tested various math libraries back in the day.

Hi Andrew. Here are my benchmark results for each operation used is math_dashu.rs:

If you’d like to dive deeper into the benchmark data, I’d be happy to share a Dropbox link or any other format that works for you.

[AndrewWestberg]

ln, pow, ref_ln, and ref_pow are pretty heavily utilized in validating the block headers. This confirms what I found when I built out and tested num_bigint originally. For those important operations, it's not quite 2x as slow, but it's close.

In my testing (less formal), rug was the fastest but incompatible on windows. Malachite was next best, but the developer wouldn't change the license. Dashu was after that and num_bigint was the slowest.

If you want to dig through the version history of pallas_math, you can probably find my implementations of all of these.

[Quantumplation]

@scarmuega @KtorZ how would you like to proceed here? I see a couple of options:

• if the goal is to just always use one math library, we migrate to dash instead of num bigint
• alternatively, we could try to upstream some optimizations to num bigint
• if we're in micro optimization territory, we could just live with the slowdown

[KtorZ]

I would prefer sticking to one library; and I don't think the performances should be the sole argument. Both libraries have very decent perfs and I hardly think that any will constitute a bottleneck in block header validations.

Also, rather than comparing rust libs against one another in terms of perfs, we should compare rust lib with the current Haskell implementation. Because if they're all slower, then they all equally suck :).

But what are the other factors?

• interoperability / cross compilation: and on that regard, since we already cross compile our header validation code just fine with dashu and the ledger with num-bigint; then it seems fine with both.

• maintenance / robustness: num-bigint is more established and with about half a million of daily downloads; vs 2000 downloads for dashu. So the chances that something is off in dashu vs num-bigint is unfortunately higher. Although both seems well tested; the risk with dashu is higher.

• module API: I have to say that I prefer num-bigint's API so far. But that one is purely subjective and likely due to habits.

One way for way with Pallas could be to enable either depending on feature flags; although I think Pallas already went down that path and came back? So perhaps there's no interest in supporting multiple maths libraries.

[Quantumplation]

I think all of that is sensible.

It might be worth writing a benchmark specifically for header validation, and just establish a reference budget using the haskell node numbers.

[AndrewWestberg]

The golden tests in the haskell code are a good benchmark to hit. The reference C code that haskell is matching used gmp which is used by rug.

[AndrewWestberg]

The performance of the library is quite import to cncli in the leadership calculation. If Amaru does the calculation every second like the haskell node does but performs worse, that's an issue.

My original design used rug as a feature flag so if you really wanted the best performance, you could get it.