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