[now sending to the entire group] And the plot thickens.
https://play.golang.org/p/P2JPI42YJa8 Basically, this is a very simple loop iterated with different step increments. For step increments of 1, 2, 4, 5 and 10, there are no bound checks. For step increments of 3, 6, 7, 8 and 9 there are bound checks. So, in this simplified case, if the step divides the length evenly, then there are no bound checks. If it does not, then bound checks are inserted. This seems to be an unnecessary check as the actual relevant thing is to make sure that the index is not equal to or greater than the slice length. Either that or I am missing something On Fri, Feb 21, 2020 at 10:24 AM Bruno Albuquerque <b...@gmail.com> wrote: > This is interesting. If I simplify the loop to something like this: > > nrgbaData := make([]byte, len(rgbData)+(len(rgbData)/3)) > > _ = nrgbaData[len(rgbData)] > > for i := 0; i < len(rgbData); i++ { > nrgbaData[i] = rgbData[i] > } > > then the bounds check at the line inside the for loop is removed. > > But if I change it to this: > > nrgbaData := make([]byte, len(rgbData)+(len(rgbData)/3)) > > _ = nrgbaData[len(rgbData)] > > for i := 0; i < len(rgbData); i += 3 { > nrgbaData[i] = rgbData[i] > } > > then the bounds check is not eliminated. > > Considering it is still guaranteed that "i" inside the loop will never be > equal to or greater than len(rgbData), I do not understand why the bounds > check is now required. > > Any ideas? > > > On Fri, Feb 21, 2020 at 10:07 AM Bruno Albuquerque <b...@gmail.com> wrote: > >> Nope. Bound checks are still there. I am puzzled by this one. >> >> >> On Fri, Feb 21, 2020 at 9:34 AM Sebastien Binet <bi...@cern.ch> wrote: >> >>> >>> >>> On Fri, Feb 21, 2020 at 5:36 PM Bruno Albuquerque <b...@gmail.com> wrote: >>> >>>> I wrote some simple code to convert a RGB24 image represented as a >>>> []byte to a NRGBA image (also as a []byte), like so: >>>> >>>> https://play.golang.org/p/Y7ICg7t4_nd >>>> >>>> Unfortunately, the performance is lacking here and I am trying to >>>> improve it. The first low hanging fruit seems to be taking advantage of >>>> BCE: >>>> >>>> $go test -bench . >>>> goos: linux >>>> goarch: amd64 >>>> BenchmarkNRGBA-8 484 2636344 ns/op >>>> >>>> $ go test -gcflags="-B" -bench . >>>> goos: linux >>>> goarch: amd64 >>>> BenchmarkNRGBA-8 855 1654882 ns/op >>>> >>>> Unfortunately, I could not find an incantation that would remove the >>>> bound checks. My naive attempt was to just do >>>> >>>> _ = nrgbaData[len(nrgbaData)-1] >>>> >>>> at around line 7 in the program above but this did not help and added >>>> one extra bound check. >>>> >>>> Funny enough, if I do >>>> >>>> _ = nrgbaData[len(nrgbaData)] >>>> >>>> all the bound checks seem to be eliminated but, obviously, the program >>>> panics at this line. >>>> >>> what about: >>> _ = nrgbaData[:len(nrgbaData)] >>> >>> does this also remove the bound checks? >>> >>> -s >>> >> -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEd86Tw_1qLzK4HEw9rA06Wqnrtzs6CuzMT6VAK3Y40Bs7yPBw%40mail.gmail.com.
