I managed to do quite a bit better (30% savings in execution time)
proceeding along these lines. Finally I got to the point where
runtime.makeslice, and underneath runtime.mallocgc, are responsible for 50%
of the run time, with no other real hotspots. Almost all of the makeslice
time is coming from math/big.nat/mul, in this section:
. . 420: // use basic multiplication if the numbers
are small
100ms 100ms 421: if n < karatsubaThreshold {
100ms 9.13s 422: z = z.make(m + n)
180ms 3.13s 423: basicMul(z, x, y)
150ms 390ms 424: return z.norm()
. . 425: }
This z.make statement is what is doing it, and I don't see any way to
control it ... it's buried deep in the math/big package, and n has to do
with the length of a passed big.Int argument, that length "is what it is"
and is apparently always under this karatsuba Threshold, so the make
*always* gets called.
Any other suggestions? :-)
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
