Consider using an alternative to num for multiple precision arithmetic

[vks]

num is one of the less efficient implementations of multi-precision arithmetic. (IIRC it is several orders of magnitude slower than GMP.) It might be worthwhile to use ramp (requires nightly and does not have fractions) or rust-gmp (bindings to C lib) instead.

[murarth]

Performance was not my biggest concern, but I am open to replacing the num crate. However, I want to keep this project running on stable and open to users of the stable branch.

I've also considered that maybe a FixedNum(i64) variant of Value (which would transparently upgrade to arbitrary-precision when necessary) might also be a worthwhile performance enhancement. But I suppose that's true irrespective of which integer crate is used.

[hauleth]

@vks there is work on improving num crate. We want to split it into separate crates and leave num as "meta-crate" that will bring everything together for compatibility. So if you have some thoughts how to improve num feel free to PR :)

[vks]

@hauleth I think the split is a good idea. I wrote down my thoughts in rust-num/num#102.

[hauleth]

@vks I know. I am one of the maintainers. Also I started work on that issue rust-num/num#164 to achieve that.

[cuviper]

@vks when was the last time you checked num's bigint performance? It has seen significant performance work more recently than rust-num/num#102 was filed. I'm sure any library that uses asm will still be faster, but bigint is much better now.

[vks]

@cuviper It was at least a year ago. I'll dig up my use case, port it to num and evaluate the performance again. (I think it was calculating the discrete logarithm.)

[vks]

@cuviper Performance is much better now, it is only one order of magnitude slower than GMP. (I also had to implement a few algorithms that are not provided by num that might be suboptimal.)

See rust-num/num#181.