murarth
Consider using an alternative to num for multiple precision arithmetic
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.
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.
@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 :)
@hauleth I think the split is a good idea. I wrote down my thoughts in https://github.com/rust-num/num/issues/102.
@vks I know. I am one of the maintainers. Also I started work on that issue rust-num/num#164 to achieve that.
@vks when was the last time you checked num's bigint performance? It has seen significant performance work more recently than rust-lang/num#102 was filed. I'm sure any library that uses asm will still be faster, but bigint is much better now.
@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.)
@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 https://github.com/rust-num/num/issues/181.