Open jorisguex opened 1 month ago
I don't think that will change until I rewrite the "backend" digit code with a custom BigInt, rather than using num-bigint::BigInt, which doesn't offer much in terms of direct access to the digits, so there's lots of cloning involved.
If you're interested you could make a flamegraph of the calls involved and maybe there's some low hanging fruit that I can pick -- but I have doubts, and wont have much time to dedicate until later this month.
Hi, thanks for your response. I have done a flamegraph and ~28% of the samples are in num_bigint::biguint::multiplication::scalar_mul
while ~72% are in num_bigint::biguint::division::div_rem_ref
.
For anyone interested, I have made a fork in the meantime that speeds up sqrt by ~100x: https://github.com/akubera/bigdecimal-rs/compare/trunk...jorisguex:bigdecimal-rs:make-sqrt-faster. It passes all of the unit tests but there may be specific edge cases where it fails (I haven't done that much testing). It also has the benefit of rounding correctly.
> cargo run --release 2>/dev/null
Precision = 100: 0.00032 seconds (3.1970801 microseconds per digit)
Precision = 1000: 0.00056 seconds (0.55525 microseconds per digit)
Precision = 10000: 0.00428 seconds (0.4282583 microseconds per digit)
Precision = 100000: 0.49238 seconds (4.923846 microseconds per digit)
I was benchmarking the
sqrt
function and I noticed that is was slower than I expected:Compare that to Python: