On Dec 4, 2013, at 6:20 PM, Alan Eliasen wrote: > Hmmm... it looks like that patch is correct and necessary if > getLower() is receiving negative numbers. I'm not quite sure what > happened there. My vague recollection was that at one point the > arguments to Karatsuba multiply were conditioned to always be positive > in the multiply() dispatching function, but that's apparently not the > case in the current code.
Thanks for the comments. There is no guarantee that the factors will not be negative. The main thing is that it got caught before the release of 8. > Thanks for letting me know about this. I didn't see the earlier bug > report or the report that the thresholds were being changed. It would > seem to me that the new thresholds are quite a bit higher than is > optimal for the architectures I tested on (Linux 64-bit and Windows 32 > bit, and a bit of Raspberry Pi Arm); I intentionally set my thresholds > to be quite high and conservative. Is there a particular architecture > that requires the thresholds to be set that high? What performance > effect do those higher thresholds have on the most common architectures? These thresholds are based on quite a few benchmark test runs on various architectures. I don't recall that there was any one particular architecture that was behind raising the thresholds. There was a lot of variability in the test runs and these values represent a best guess at retaining performance improvements afforded by the newer algorithms without provoking serious regressions. We intend to perform more testing on these thresholds on various platforms and to tune the thresholds as the data suggest. If you have any suggestion as to which are the most common architectures for these sorts of computations in your experience that would be welcome. Thanks, Brian
