Enable u64 limbs in core::num::bignum

[Kivooeo]

Since u128 is stable now, I guess, we can safely add this, not sure if this requires tests or anything

Closes #137887

[rustbot]

r? @scottmcm

rustbot has assigned @scottmcm.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[hanna-kruppe]

I’m pretty sure uncommenting this doesn’t actually do anything unless you also update the define_bignum! invocations at the bottom of the file, and update some other code to use a new u64-limb-based type.

[Kivooeo]

Thanks, I wanted to hear something like this, but I might need little bit more explanations about this

update the define_bignum! invocations at the bottom of the file

Do I have to replace this u32 with u64 and rename it to 64 as well?

pub type Digit32 = u32;

define_bignum!(Big32x40: type=Digit32, n=40);

And update this name in other places like imports and tests?

[hanna-kruppe]

I don’t know if I can provide much guidance here. I haven’t touched this code in about ten years and the parts I’ve worked on have almost entirely been replaced by now. The only thing I can tell you is that simply replacing the existing u32 limbs with u64 limbs will probably be a performance regression on 32 bit targets. A straight replacement is probably easier to try out (to see if it gives any performance gains) but a version that can happily be merged will probably have to grapple with using different bignum types based on some cfg(…)s.

[Kivooeo]

I like your idea with cfg, but I wonder about how can I benchmark code in core? Is there any tools or something I can use to measure bignum performance before and after changes

[hanna-kruppe]

It used to be used in the slow paths of dec2flt and flt2dec. From a quick code search on GitHub, only flt2dec is still using it. I don’t know off-hand how to find a benchmark that takes that particular code path.

[Kivooeo]

I tried a full replacement locally and saw the extensive fallout in tests and constants. It's a much larger change than I initially thought.

Given the scope and the risk of regression on 32-bit, I'll keep this PR minimal and just uncommenting the line to clean up the obsolete comment. The architectural shift to cfg-based types is better suited for a dedicated effort.