2017-07-17 15:56 GMT+02:00 Jeff Templon <jeff.templon.nik...@gmail.com>:
> 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!
>
How are you writing your code ? Wisely using variables should only
cause very minimal memory allocation.
Rémy.
--
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.
