Optimized Ord::cmp function

[mikem8891]

This implementation of the Ord::cmp function does several early comparisons to try to determine ordering before resulting to div and mod operations. This allows about half of unsigned Ratio<T> pairs and 3/4 of signed Ratio<T> pairs to be determined using simple comparisons (based on the entire input space, individual results may vary). If simple comparisons don't determine the ordering, then the function enters a tight loop to converge on a solution as quickly as possible.

Note, #121 would be faster, but would still benefit from this pull request if checked_mul returns None.

I confirmed this fixes #140 . This solution is iterative instead of recursive.

This should also fixes #146 . I phoned this in because I think negative denominators should not be adversely affecting performance or complexity compared to normal fractions.

For context, here are some benchmark results

new_test_cmp_overflow   time:   [1.8502 µs 1.8865 µs 1.9358 µs]
Found 17 outliers among 100 measurements (17.00%)
  3 (3.00%) high mild
  14 (14.00%) high severe

old_test_cmp_overflow   time:   [2.3391 µs 2.3740 µs 2.4193 µs]
Found 6 outliers among 100 measurements (6.00%)
  5 (5.00%) high mild
  1 (1.00%) high severe

I can make this benchmark available to you if needed.

This is a repost of #147 because I accidentally closed it after the crate was refactored into modules.

[cuviper]

I have in mind a way to make the current code iterative without changing the overall approach as much. I would at least like to compare that to yours, so if you could share your benchmark, that would be great.

[mikem8891]

https://github.com/mikem8891/num-bench

cargo run tests #140

cargo bench benchmarks Ord::cmp function in the crate in the num-rational folder to the num-rational crate in crates.io, per the Cargo.toml snippet below.

[dependencies]
old-num-rational = {version = "0.4.2", package = "num-rational"}
new-num-rational = {path = "num-rational", package = "num-rational"}

[cuviper]

Hmm, with your code I get these results on my Ryzen 7 9800X3D:

new_test_cmp_overflow   time:   [926.51 ns 929.73 ns 932.86 ns]
old_test_cmp_overflow   time:   [820.24 ns 820.61 ns 820.95 ns]

There must be some large architectural difference in our CPUs -- branch predictor? div cycles?

My own iterative code gets around ~848ns, so I need to figure out what that has lost too, but it's close.

[cuviper]

As part of mine, I also have a test over all i8 ratios (with positive denom), and your implementation trips here comparing -128/x and -1/1, overflowing -128/-1.