karatsuba multiplication by dlesnoff updated to use openarrays#148
karatsuba multiplication by dlesnoff updated to use openarrays#148metagn wants to merge 25 commits intonim-lang:masterfrom
Conversation
Co-authored-by: konsumlamm <44230978+konsumlamm@users.noreply.github.com>
Co-authored-by: konsumlamm <44230978+konsumlamm@users.noreply.github.com>
Add recent changes in the library.
Karatsuba only works in running time. Strange errors when the tests are executed as static. I commented for the present. Tests should be moved from main to tbigints.nim
…snoff-karatsuba
|
Thanks very much for looking into it! I am in the last weeks of my PhD's writing so I can't review it now but soon. This piece of code convinced my advisors to recruit me as it showed my interest for multiple precision arithmetic. They did not check for the validity or correctness of the code. It brings back some souvenirs :) Karatsuba is a specific variant of the Toom-Cook algorithm. In the GMP library, the threshold is said to be only 10 limbs: https://gmplib.org/manual/Karatsuba-Multiplication#index-Karatsuba-multiplication but we should not compare against this kind of library! I appreciate your changes. I just don't want to give you high hopes on the usability of the library after these changes. |
Updates #95 by @dlesnoff to address the comments. The raw limb parameters might look awkward but I doubt anyone cares after 4 years.
I am only going off of what I understood from the issue comments, otherwise I am not knowledgeable about this. I could not come up with better test code than the original PR and I could not say how to make this algorithm better other than Nim-specific speedups. I wouldn't complain if this doesn't get merged because there's no one around to review it with confidence, only took about an hour.
Based off of timing
fastMultiplication.nim(renamed tobench_multiplication.nim) which just multiplies 10000 digit numbers, a minimum threshold of 80 limbs gives a speedup of about 2x on my computer. Going above this number does not make much of a difference but below significantly slows down, and it is the threshold used in the Java BigInteger implementation, so I went with it, but another number could also be used. Maybe it could be made configurable/not a constant but for a library this small it is probably less effort to just copy the file locally and change the number.I did this because I thought this was a big obstacle in this library being usable but from what I understand all this really does is gradually and slowly improve the performance after around 800 digits which is already pretty high. It might be better to focus on making integers between 64 and 2-4k bits faster instead. The library seems to be missing simple optimizations like selectively disabling Nim checks, inlining etc let alone using CPU specific primitives, there are also some missing basic functions like
modmulandlcm(for easy rationals, though not sure if there is an optimized version of it separate fromgcd).