BigInteger performance improvements
eliasen at mindspring.com
Thu Jan 31 04:22:57 UTC 2008
I'm planning on tackling the performance issues in the BigInteger
class. In short, inefficient algorithms are used for
multiplication, exponentiation, conversion to strings, etc. I intend to
improve this by adding algorithms with better asymptotic behavior that
will work better for large numbers, while preserving the existing
algorithms for use with smaller numbers.
This encompasses a lot of different bug reports:
4228681: Some BigInteger operations are slow with very large numbers
(This was closed but never fixed.)
4837946: Implement Karatsuba multiplication algorithm in BigInteger
I've already done the work on this one. My implementation is
intended to be easy to read, understand, and check. It significantly
improves multiplication performance for large numbers.
4646474: BigInteger.pow() algorithm slow in 1.4.0
This will be improved in a couple ways:
* Rewrite pow() to use the above Karatsuba multiplication
* Implement Karatsuba squaring
* Finding a good threshhold for Karatsuba squaring
* Rewrite pow() to use Karatsuba squaring
* Add an optimization to use left-shifting for multiples of 2 in the
base. This improves speed by thousands of times for things like
4641897: BigInteger.toString() algorithm slow for large numbers
This algorithm uses a very inefficient algorithm for large numbers.
I plan to replace it with a recursive divide-and-conquer algorithm
devised by Schoenhage and Strassen. I have developed and tested this in
my own software. This operates hundreds or thousands of times faster
than the current version for large numbers. It will also benefit from
faster multiplication and exponentiation.
In the future, we should also add multiplication routines that are
even more efficient for very large numbers, such as Toom-Cook
multiplication, which is more efficient than Karatsuba multiplication
for even larger numbers.
Has anyone else worked on these? Is this the right group?
I will probably submit the Karatsuba multiplication patch soon.
Would it be more preferable to implement *all* of these parts first and
submit one large patch?
Alan Eliasen | "Furious activity is no substitute
eliasen at mindspring.com | for understanding."
http://futureboy.us/ | --H.H. Williams
More information about the core-libs-dev