Coming back to this, now that my Go knowledge is increasing:
On Saturday, July 8, 2017 at 5:58:59 PM UTC+2, Andy Balholm wrote:
>
> I noticed your “naive explanation” after I sent my message. But I think it
> is the real explanation.
>
it turns out that 77% of the time of the program is spent in
runtime.mallocgc :-) I think the reason why is stuff like this:
func (z nat) shr(x nat, s uint) nat { m := len(x) n := m - int(s/_W)
if n <= 0 { return z[:0] } // n > 0 z = z.make(n)
shrVU(z, x[m-n:], s%_W) return z.norm()
}
If I understand it right, there are two "make slice" operations in this
code, and this bit is being run billions of times (heart of a tight loop).
Given the way Go works, the GC is unavoidable. I've managed to make the
code slightly faster by both swapping right-shift in instead of a Mod
(Barrett reduction) and also avoiding my own object creation inside the
loop, and there is 10 to 20% to be won by playing with GOGC, but the only
way to do better is probably to rewrite the math/big library. I tried
using GMP but given all the temporaries created, it was even worse than
using math/big!
--
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.
