Re: [go-nuts] pointer dereference optimization in loops

2018-11-30 Thread robert engels
According to Dobb’s, http://www.drdobbs.com/cpp/type-based-alias-analysis/184404273 , many compilers do this today to some degree. > On Nov 30, 2018, at 2:51 PM, robert engels wrote: > > I’m not so sure about this case, as a smar

Re: [go-nuts] pointer dereference optimization in loops

2018-11-30 Thread robert engels
I’m not so sure about this case, as a smart compiler might decide the loop warrants alias checking, and then might only perform a single load and store and perform all of the computations in registers (or unroll them completely). I am not aware of compilers doing this today, but they certainly c

Re: [go-nuts] pointer dereference optimization in loops

2018-11-30 Thread robert engels
Then rewrite it this way func SomeFunc() { count:= 1 p := &count total := 0 for i:=0;i<10;i++ { total = total + *p someOtherFunc() } } it should definitely be optimized away in this case. > On Nov 30, 2018, at 12:09 PM, Jakob Borg wrote: > >

Re: [go-nuts] pointer dereference optimization in loops

2018-11-30 Thread Burak Serdar
On Fri, Nov 30, 2018 at 11:09 AM Jakob Borg wrote: > > This should only be valid for a loop that doesn’t include any function calls, > or if the compiler can prove that said function calls don’t involve any > synchronization primitives anywhere in the possible call stack. ...or any potential po

Re: [go-nuts] pointer dereference optimization in loops

2018-11-30 Thread Jakob Borg
This should only be valid for a loop that doesn’t include any function calls, or if the compiler can prove that said function calls don’t involve any synchronization primitives anywhere in the possible call stack. So maybe it’s optimized in for … { total += *p } but I wouldn’t bet on it in

Re: [go-nuts] pointer dereference optimization in loops

2018-11-30 Thread robert engels
I would think the compiler would be free to optimize this as a single load outside the loop - as Go has no volatile declaration (to inform the compiler that some other thread might of changed the value of *p) > On Nov 30, 2018, at 11:58 AM, robert engels wrote: > > It’s as simple as: > > var

Re: [go-nuts] pointer dereference optimization in loops

2018-11-30 Thread robert engels
It’s as simple as: var count = 1 var p = &count func X() { total :=0 for i:=0; i <100;i++ { total = total + *p } } no ? > On Nov 30, 2018, at 11:48 AM, Mark Volkmann wrote: > > I think I failed to come up with a good code example. But suppose I need to > do something with a point

Re: [go-nuts] pointer dereference optimization in loops

2018-11-30 Thread Mark Volkmann
I think I failed to come up with a good code example. But suppose I need to do something with a pointer inside a loop that really does require dereferencing it and the pointer never changes inside the loop. In that case will the Go compiler optimize that so the dereference doesn't happen in each lo

Re: [go-nuts] pointer dereference optimization in loops

2018-11-30 Thread Jan Mercl
On Fri, Nov 30, 2018 at 6:16 PM Mark Volkmann wrote: > Will the Go compiler optimize the pointer dereference so it doesn't happen in every loop iteration? If not, is it common practice to do that outside the loop like this? > > myValue := *myPtr > for _, v := range values { > fmt.Printf("