FYI, strided iteration is something we're trying to do better but this is
very tricky code, and it is also possible for it to get very expensive at
compile time.
On Saturday, February 22, 2020 at 4:42:03 PM UTC-5 Nigel Tao wrote:
> On 2/23/20, Bruno Albuquerque wrote:
> > Would adding an expl
On 2/23/20, Bruno Albuquerque wrote:
> Would adding an explicit len() check before the loop help the
> compiler in any way (can not test right now)?
I don't know. Sorry.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this g
Fair enough. This would never happen in practice but the compiler has no
way to know. Would adding an explicit len() check before the loop help the
compiler in any way (can not test right now)?
Concerning Swizzle: Although what I am doing is technically a color space
conversion, going from RGB to
Ah. Now it makes more sense. I completely abstracted away overflows (again,
not a scenario that would happen in practice in any case).
On Sat, Feb 22, 2020 at 3:54 AM Nigel Tao wrote:
> On 2/22/20, Bruno Albuquerque wrote:
> > https://play.golang.org/p/P2JPI42YJa8
> >
> > ...
> >
> > So, in thi
On Saturday, 22 February 2020 11:54:43 UTC, Nigel Tao wrote:
>
>
> 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-negat
On 2/22/20, Bruno Albuquerque 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
On 2/22/20, Bruno Albuquerque wrote:
> https://play.golang.org/p/Y7ICg7t4_nd
>
> ...
>
> Unfortunately, I could not find an incantation that would remove the bound
> checks.
The code from that play.golang.org link is:
func NRGBA(rgbData []byte) []byte {
nrgbaData := make([]byte, len
Curious, in the cases of where you were able to eliminate the bounds checks
what was the performance difference in the overall process?
I would be very surprised, even in matrix type loops, that this makes an
appreciable difference given modern cpu branch predictors.
I think a better area of a
[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 b
got it down to two:
https://play.golang.org/p/jmTqhLGaLY_T
On Fri, Feb 21, 2020 at 11:24 AM Bruno Albuquerque wrote:
>
> This is interesting. If I simplify the loop to something like this:
>
> nrgbaData := make([]byte, len(rgbData)+(len(rgbData)/3))
>
> _ = nrgbaData[len(rgbData)]
>
>
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 insi
Nope. Bound checks are still there. I am puzzled by this one.
On Fri, Feb 21, 2020 at 9:34 AM Sebastien Binet wrote:
>
>
> On Fri, Feb 21, 2020 at 5:36 PM Bruno Albuquerque wrote:
>
>> I wrote some simple code to convert a RGB24 image represented as a []byte
>> to a NRGBA image (also as a []by
On Fri, Feb 21, 2020 at 5:36 PM Bruno Albuquerque 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 impr
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 B
14 matches
Mail list logo
