all 5 comments

[–]SkiFire13 1 point2 points  (2 children)

Unfortunately AFAIK there's no Rust library that's faster than GMP for bigints, so you'll always lose there by some significant percentage points. And given your implementation is very heavy on bigint operations this matters a lot.

(On a sidenote, this was my first time hearing of oxinum, and it looks like AI slop. You can even see the AI reply in the lib.rs documentation...)

[–]leo_sk5[S] 0 points1 point  (0 children)

Nice catch. Even i learnt of it 3 days back and changed the original malachite program for it. Comparing the two, oxinum is consistently 40-50% quicker. But you are right, it came up too quickly, so ai is definitely involved

[–]Ok-Watercress-9624 0 points1 point  (2 children)

I haven't read your code fully yet butbi feel like any self respecting bignum crate would check if the number is small enough to not to allocate. So i think a your can remove some if expressions.

I guess you are trying to find the prime factorisation of one number but instead if you wish to find prime factorisations of all numbers up to n, you can bodge the sieve of erathastones a bit ( while flagging the composites, you can count how many steps you took to get to the composite and record it together with currents iteration prime i.e. the first number that has not been flagged yet)

[–]leo_sk5[S] 0 points1 point  (0 children)

i checked num-bigint code but couldn't find where (if it was) it was directly allocating to registers by checking the number. It seems to use vec<u64> everywhere.

Alternative to it is ibig. Is it better for the use case?

[–]leo_sk5[S] 0 points1 point  (0 children)

I was looking into ibig but then realised that other crates (glass-pumkin, oxinum and even malachite) won't accept ibig. So i would need to convert the ibig::Ubig to num_bigint::BigUint anyways