Re: [go-nuts] Newbie question on slice bound checking

[Jan Mercl]

On Aug 26, 2012 6:50 PM, "Bluehorn" <blue...@gmail.com> wrote:
>
> If the "range" keyword is used in the "for" loops, will array/slice index bound checking be disabled?
>

They are not disabled. It's much better, they're not at all needed while using the range statement ;-)

-j

[minux]

On Sun, Aug 26, 2012 at 5:52 PM, Bluehorn <blue...@gmail.com> wrote:

I'm new to the Go language, trying to convert some algorithms previously written in C into Go packages.  I got about 2x run time in Go compared to C.

The algorithm mainly uses 2-dimensional matrix operations. In Go, slice of slices are used instead of 2-dimension matrices in C.  I suspect that the run time difference is mainly due to bound checking on array access.  After studying the Go documents and searching this group, I'm still not sure of the following question:

If the "range" keyword is used in the "for" loops, will array/slice index bound checking be disabled?

if you want to disable boundary check without changing code, pass -gcflags -B to go run/build/install, etc.

example:

go build -gcflags -B somePkg

[Jesse McNelis]

On Sun, Aug 26, 2012 at 7:52 PM, Bluehorn <blue...@gmail.com> wrote:
> The algorithm mainly uses 2-dimensional matrix operations. In Go, slice of
> slices are used instead of 2-dimension matrices in C. I suspect that the
> run time difference is mainly due to bound checking on array access.

Slices of slices are different to 2-dimensional arrays in C.
A 2-dimensional array in C is contiguous memory.
A slice of a slice means that there is a separate allocation for each
slice, which means more indirection and increased possibility of cache
misses.

Since 2-dimension arrays in C are just syntactic sugar, you can get
the same thing in Go it just won't look as nice.
ie.
someSlice[x*y] is the same as someCarray[x][y]



--
=====================
http://jessta.id.au

[Dan Kortschak]

On Mon, 2012-08-27 at 09:21 +1000, Jesse McNelis wrote:
> Since 2-dimension arrays in C are just syntactic sugar, you can get
> the same thing in Go it just won't look as nice.
> ie.
> someSlice[x*y] is the same as someCarray[x][y]
>

someSlice[x*stride+y]

[bluehorn]

Thanks for all the helpful comments. After revising most of the "for"
loops with range statement and avoiding direct indexing of slides
(such as s[ind]), I get the program run time down to about 150% of the
"C" version. I will try to see if there are other optimization
techniques possible.

Is "-gcflags -B" still supported in go1.0.2? I suppose it was gone already.

[minux]

On Monday, August 27, 2012, bluehorn wrote:

Is "-gcflags -B" still supported in go1.0.2?  I suppose it was gone already.

It is still there. 

[Rémy Oudompheng]

On 2012/8/27 bluehorn <blue...@gmail.com> wrote:
> Thanks for all the helpful comments. After revising most of the "for"
> loops with range statement and avoiding direct indexing of slides
> (such as s[ind]), I get the program run time down to about 150% of the
> "C" version. I will try to see if there are other optimization
> techniques possible.

You should take into account compiler differences before trying optimizations.
Did you try gccgo ?

Rémy.

[Bluehorn]

Thanks for the suggestion. 

With "-compiler=gccgo -gccgoflags=-O3", I got the run time down to about 130% of the C equivalent.  That is encouraging :)

I guess future improvement in the Go tools may bring better results.  For now, it is good enough for me to go on to convert my other programs into Go packages.

Cheers!

[DisposaBoy]

On Monday, August 27, 2012 10:18:23 AM UTC+1, Bluehorn wrote:

Thanks for the suggestion. 

With "-compiler=gccgo -gccgoflags=-O3", I got the run time down to about 130% of the C equivalent.  That is encouraging :)

I guess future improvement in the Go tools may bring better results.  For now, it is good enough for me to go on to convert my other programs into Go packages.

Cheers!
 

... a bit late to the part, but: have you tried profiling? if nothing else it will likely pin-point the hotspots which may or may not even the due to the bounds checking. e.g you may be creating a lot of garbage and not even notice or checking a variable multiple times when you could've checked it once and reused a variable with the original result

 

[Sebastien Binet]

yeah... that's where generics and operator overloading would shine.

*or* have a builtin n-dim slice...

-s

[DisposaBoy]

No. That would most likely make things worst by masking the problem which has nothing to do with generics, whatever that means.

 

[Sebastien Binet]

DisposaBoy <dispo...@dby.me> writes:

> On Monday, August 27, 2012 12:10:59 PM UTC+1, Sebastien Binet wrote:
>>

>> Dan Kortschak <dan.ko...@adelaide.edu.au <javascript:>> writes:
>>
>> > On Mon, 2012-08-27 at 09:21 +1000, Jesse McNelis wrote:
>> >> Since 2-dimension arrays in C are just syntactic sugar, you can get
>> >> the same thing in Go it just won't look as nice.
>> >> ie.
>> >> someSlice[x*y] is the same as someCarray[x][y]
>> >>
>> >
>> > someSlice[x*stride+y]
>>
>> yeah... that's where generics and operator overloading would shine.
>>
>> *or* have a builtin n-dim slice...
>>
>> -s
>>
>
> No. That would most likely make things worst by masking the problem which
> has nothing to do with generics, whatever that means.

so you'd be more in favor of the builtin n-dim slice, then ?


-s

[Ugorji Nwoke]

I know this is an old thread, but is -B still supported?

[Michael Jones]

It has been, yes, and unless it changed in the last few weeks, it still is. 

I use to to measure cost as an awareness metric, but seldom run that way. Go is safe until you do that, then it becomes unsafe. Too risky for serious use. 

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/397c0824-b5b5-412d-974e-b53f56d29a82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Michael T. Jones
michae...@gmail.com

[Jan Mercl]

On Sun, Jun 16, 2019, 13:53 Ugorji Nwoke <ugo...@gmail.com> wrote:

I know this is an old thread, but is -B still supported?

That compiler flag provides compiling a program, semantic of which isn't compatible with the Go language specification.

It's only valid use is to enable easy evaluation of the bounds checking costs.

That said, I don't think the term "supported" applies. It's just a compiler developer's tool.

[Ugorji Nwoke]

Thanks much, to you and Jan Merci.

I needed it to validate whether the performance gap in my library was due to bounds checking or not. If it was, then I would try harder to use tips to reduce bounds checking. I wasn't planning on running it in production.

I ended up having to use -gcflags=all=-B (previously I was only using -gcflags=-B and I didn't see any improved performance for any packages).

On Sunday, June 16, 2019 at 9:34:17 AM UTC-4, Michael Jones wrote:

It has been, yes, and unless it changed in the last few weeks, it still is. 

I use to to measure cost as an awareness metric, but seldom run that way. Go is safe until you do that, then it becomes unsafe. Too risky for serious use. 

On Sun, Jun 16, 2019 at 4:53 AM Ugorji Nwoke <ugo...@gmail.com> wrote:

I know this is an old thread, but is -B still supported?

On Monday, August 27, 2012 at 2:09:19 AM UTC-4, minux wrote:

On Monday, August 27, 2012, bluehorn wrote:

Is "-gcflags -B" still supported in go1.0.2?  I suppose it was gone already.

It is still there. 

--
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 golan...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/397c0824-b5b5-412d-974e-b53f56d29a82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.