Hi Remy,

It turns out that you are at least partially on the right track :-)  I 
changed the way Barrett is written, so as to use as few temporary variables 
as possible.  In particular, the Rsh doesn't use any at all anymore ... the 
60% of the Rsh time that was being used in runtime.mallocgc disappeared, 
resulting in a bit more than 10% overall performance improvement in the 
entire code.  Now I understand better the comments about reuse of arguments 
in the math/big documentation!   Thanks for your suggestion.



On Tuesday, July 18, 2017 at 9:09:54 AM UTC+2, Jeff Templon wrote:
>
> Hi Remy,
>
> On Monday, July 17, 2017 at 10:39:56 PM UTC+2, Rémy Oudompheng wrote:
>>
>> 2017-07-17 15:56 GMT+02:00 Jeff Templon <jeff.temp...@gmail.com>: 
>>
>  
>
>> > 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() 
>> > 
>> >   } 
>> > 
>>
>> How are you writing your code ? Wisely using variables should only 
>> cause very minimal memory allocation. 
>>
>>
> It's not my code that is taking all the time ... it's math/big itself. 
>  The way I understand it, for example in the above code, x[m-n:] creates a 
> three-byte slice object.  In the tightest part of the loop of my code, this 
> function is called twice, for a million loop iterations this is already 3 
> MB that will need to be garbage collected, and this is not the only 
> function being called.  
>
> I include the profile for a short run, you can see most of the time is 
> spent in routine "Barrett", of which almost all that time is spent in 
> functions in math/big, tracing through the graph you can see that 
> ultimately most of that time is spent inside runtime.mallocgc ... is there 
> a way to call math/big functions that does not result in so much garbage 
> collection?
>
>

-- 
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.

Reply via email to