On Thursday, 28 July 2016 03:40:39 UTC+3, Carl Ranson wrote:
>
> Thanks Egon,
>
> Ok, I take your point that one needs to strike a balance with the work
> done in each goroutine to achieve optimum performance.
> i understand that each goroutine doing a subblock of the board using
> bitmaps would be faster, but as a learning exercise i'm keeping it simple.
> In fact I was pleasantly surprised by how simply the code came out once I
> could think about each cell's calculation as a discrete process.
>
> one part of your answer I didn't understand was the bit about pointers.
>
>> Try to avoid pointers in a tight loop. Following a pointer is not free.
>>
>> This can be simplified:
>> if c.nw.currentState {
>> i++
>> }
>> with
>> i += count(c.nw) // define count somewhere
>>
>
> what would the count function do that alleviates it from the need to
> follow the pointer? Are you saying that testing the pointer for nil costs
> less than dereferencing the pointer? even if true that doesn't help me here
> as every cell always has 8 neighbors (its not dependent on the cell being
> live or not)
>
Those were two separate points :)... I guess using bullet-points would have
made it clearer.
One was just about pointer derefing, the other about the repetitive code.
PS: using an array could make it shorter as well, e.g. [8]*Cell
> one of the reasons I used pointers here was to avoid each goroutine from
> fighting over access to the boards array. they only care about the adjacent
> cells after all.
>
> thanks,
> CR
>
--
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.
