Marc:
Here's a _num.scm with some small tweaks to the fft multiplication code. Memory allocation is cut by roughly 40% when squaring large integers; memory allocation is also cut when the length of one integer is > 2^M bits, but the some of the lengths of the two integers is <= 2^{2M} bits. And I've defined a new macro for the constant inexact-pi/4 to remove a small dependence on the accuracy of the atan routine on fft multiplication. (It still depends on the accuracy of sin and cos in the interval [0,pi/4), which, on all modern systems, is excellent.)
So, we have
Old:
(time (* 0 (* (expt 3 1000000) (expt 3 100001))))
(time (* 0 (* (expt 3 1000000) (expt 3 100001)))) 427 ms real time 424 ms cpu time (340 user, 84 system) 22 collections accounting for 45 ms real time (14 user, 30 system) 43347960 bytes allocated no minor faults no major faults
New:
(time (* 0 (* (expt 3 1000000) (expt 3 100001))))
(time (* 0 (* (expt 3 1000000) (expt 3 100001)))) 422 ms real time 388 ms cpu time (334 user, 54 system) 24 collections accounting for 38 ms real time (23 user, 16 system) 38710968 bytes allocated no minor faults no major faults 0
Old:
(time (* 0 (expt 3 1000000)))
(time (* 0 (expt 3 1000000))) 200 ms real time 194 ms cpu time (162 user, 32 system) 13 collections accounting for 17 ms real time (9 user, 8 system) 17846920 bytes allocated no minor faults no major faults 0
New:
(time (* 0 (expt 3 1000000)))
(time (* 0 (expt 3 1000000))) 172 ms real time 167 ms cpu time (150 user, 17 system) 10 collections accounting for 12 ms real time (9 user, 3 system) 13683504 bytes allocated no minor faults no major faults 0
Brad
Afficher les réponses par date
Thanks Brad! I've integrated the new _num.scm into the runtime and all the tests I have pass.
Marc
On 18-May-06, at 3:08 PM, Bradley Lucier wrote:
Marc:
Here's a _num.scm with some small tweaks to the fft multiplication code. Memory allocation is cut by roughly 40% when squaring large integers; memory allocation is also cut when the length of one integer is > 2^M bits, but the some of the lengths of the two integers is <= 2^{2M} bits. And I've defined a new macro for the constant inexact-pi/4 to remove a small dependence on the accuracy of the atan routine on fft multiplication. (It still depends on the accuracy of sin and cos in the interval [0,pi/4), which, on all modern systems, is excellent.)
So, we have
Old:
(time (* 0 (* (expt 3 1000000) (expt 3 100001))))
(time (* 0 (* (expt 3 1000000) (expt 3 100001)))) 427 ms real time 424 ms cpu time (340 user, 84 system) 22 collections accounting for 45 ms real time (14 user, 30 system) 43347960 bytes allocated no minor faults no major faults
New:
(time (* 0 (* (expt 3 1000000) (expt 3 100001))))
(time (* 0 (* (expt 3 1000000) (expt 3 100001)))) 422 ms real time 388 ms cpu time (334 user, 54 system) 24 collections accounting for 38 ms real time (23 user, 16 system) 38710968 bytes allocated no minor faults no major faults 0
Old:
(time (* 0 (expt 3 1000000)))
(time (* 0 (expt 3 1000000))) 200 ms real time 194 ms cpu time (162 user, 32 system) 13 collections accounting for 17 ms real time (9 user, 8 system) 17846920 bytes allocated no minor faults no major faults 0
New:
(time (* 0 (expt 3 1000000)))
(time (* 0 (expt 3 1000000))) 172 ms real time 167 ms cpu time (150 user, 17 system) 10 collections accounting for 12 ms real time (9 user, 3 system) 13683504 bytes allocated no minor faults no major faults 0
Brad
<_num.scm>