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.