Comparisons to Ramp

[brendanzab]

I've looked around for permissively licensed, arbitrary precision integer libraries, and I also came across @Aatch's ramp crate, which also seems more feature complete. I was thinking it might be interesting to see some kind of comparison between the two libraries.

[Robbepop]

This is an interesting question!

I was not aware of the existant of the Ramp crate and briefly looked into it for some superficial comparison. Ramp is truly much more feature complete than ApInt, it covers more functionality (rationals and floats, too) and I guess it performs pretty well (but this is just a guess) since its even using assembly under the hood which I do not strive for in ApInt. So if you develop on nightly and are using num's BigInt before you may think about switching to Ramp instead.

I've looked at Ramp's Int data structure which is exactly this:

pub struct Int {
    ptr: Unique<Limb>,
    size: i32,
    cap: u32
}

Compared to the data structure used in ApInt:

pub struct ApInt {
    len : BitWidth,
    data: ApIntData
}

union ApIntData {
    inl: Digit,
    ext: Unique<Digit>
}

One can see that both libraries handle their types very differently and I can assume that Ramp's integer type is very similar to num's BigInt or BigUInt. Ramp's integer type seems not to be space-optimized for small values and thus will always allocate on the heap. It grows and shrinks to its required bitwidth automatically while ApInt took the approach of LLVM's APInt facility that provides the user with more controle and has its focus on hardware compatibility to emulate things like compile-time evaluation and its main goal (besides being very fast) is to be correct.

[Robbepop]

@brendanzab is the comparison sufficient enough for your evaluation? If so, I'd like to close this issue. :)

[brendanzab]

Yup, thanks!