Performance improvements for factor #1525
Commits on May 24, 2020
-
factor: Refactor (eheh) around a
FactorsdatatypeIt is clearer to see what is going on, as opposed to passing around an unmarked `Vec<u64>`, and there is a single place to add invariants checks. This is also a more compact memory representation: each prime factor is represented only once, with an additional byte for multiplicity. The performance impact is however not significant.
-
factor: Move each factorisation method to its own module
Also decoupled the factorisation methods; now factor::factor contains the logic that chains the different algorithms and aggregates results. As a side-effect, rho::factor now performs extraneous allocations (as each recursive step creates a new `Factors` value, which is then aggregated into the previous one) but there is no significant performance impact.
-
factor::factor: Use u64::trailing_zero instead of iterated division
No significant performance impact (most of the time is spent elsewhere), but an easy and satisfying fix nevertheless.
-
factor::factor: Short-circuit the fallback to Pollard's rho
When the remainder is smaller than the max. entry in the table, it is guaranteed to be prime.
-
factor::table: Remove extraneous calls to the primality test
50% performance improvement on factoring all numbers between 2 and 10⁶.
-
-
factor::factor: Remove extraneous call to the primality test
Another 6.97% runtime improvement
-
factor::miller_rabbin: Refactor before extracting dividers
Replace iterated division with u64::trailing_zeros, hoist the selection of `mul` out of the loop, another cool 49.5% runtime improvement.
-
factor::miller_rabin: Extract dividers from the primality test
Another 36% improvement.
-
-
-
factor::miller_rabin: Avoid unecessary exponentiation
Instead of computing a^r and a^(n-1) = a^(r 2ⁱ) separately, compute the latter by repeatedly squaring the former. 33.6% performance improvement
-
factor::Factors::add: Split up to work without NLL
Co-authored-by: Roy Ivy III <rivy.dev@gmail.com>
