On 2/22/20, Bruno Albuquerque <b...@gmail.com> wrote: > https://play.golang.org/p/P2JPI42YJa8 > > ... > > 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
If the step (e.g. 3) does not divide the length evenly, then e.g. "i += 3" can overflow such that i becomes negative, even though the "len(a)" in the "i < len(a)" condition is a legitimate array or slice length: a non-negative int, less than or equal to INT_MAX. See: https://play.golang.org/p/QGNKOtw3m62 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. > -- 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/CAOeFMNUHF_zE5qo1HYtq108rkOBYO36KCS_s1ZESsWLdcHQnGQ%40mail.gmail.com.
