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

[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 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 could.
> 
>> On Nov 30, 2018, at 12:13 PM, Burak Serdar > > wrote:
>> 
>> 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 pointer aliases:
>> 
>> p:=
>> q:=
>> 
>> for ... {
>>   total+=*p
>>   (*q)++
>> }
>> 
>>> 
>>> So maybe it’s optimized in
>>> 
>>> for … {
>>>  total += *p
>>> }
>>> 
>>> but I wouldn’t bet on it in
>>> 
>>> for … {
>>>  total += *p
>>>  foo()
>>> }
>>> 
>>> //jb
>>> 
>>> On 30 Nov 2018, at 19:01, robert engels >> > wrote:
>>> 
>>> 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 count = 1
>>> var p = 
>>> 
>>> 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 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 loop iteration?
>>> 
>>> On Fri, Nov 30, 2018 at 11:36 AM Jan Mercl <0xj...@gmail.com 
>>> > wrote:
 
 
 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("%v %v\n", myValue, v)
> }
 
 There's no pointer dereference inside the loop. But there's an allocation 
 inside the loop, on every iteration, that puts a pointer to a copy of 
 myValue into an interface{} that's passed to fmt.Printf. The allocation 
 can be probably avoided:
 
 myValue := interface{}(*myPtr)
 for _, v := range values {
fmt.Printf("%v %v\n", myValue, v)
 }
 
 But the %v verb handle pointers in many cases well. If that holds for the 
 type of *myPtr then simply:
 
 for _, v := range values {
fmt.Printf("%v %v\n", myPtr, v)
 }
 
 is what could be good enough.
 
 --
 
 -j
>>> 
>>> 
>>> 
>>> --
>>> R. Mark Volkmann
>>> Object Computing, Inc.
>>> 
>>> --
>>> 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 
>>> .
>>> For more options, visit https://groups.google.com/d/optout 
>>> .
>>> 
>>> 
>>> 
>>> --
>>> 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 
>>> .
>>> For more options, visit https://groups.google.com/d/optout 
>>> .
>>> 
>>> 
>>> 
>>> --
>>> 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 
>>> .
>>> For more options, visit https://groups.google.com/d/optout 
>>> .
>>> 
>>> 
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "golang-nuts" group.
>>> To unsubscribe from this group 

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

[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 could.

> On Nov 30, 2018, at 12:13 PM, Burak Serdar  wrote:
> 
> 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 pointer aliases:
> 
> p:=
> q:=
> 
> for ... {
>   total+=*p
>   (*q)++
> }
> 
>> 
>> So maybe it’s optimized in
>> 
>> for … {
>>  total += *p
>> }
>> 
>> but I wouldn’t bet on it in
>> 
>> for … {
>>  total += *p
>>  foo()
>> }
>> 
>> //jb
>> 
>> On 30 Nov 2018, at 19:01, robert engels  wrote:
>> 
>> 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 count = 1
>> var p = 
>> 
>> 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 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 
>> loop iteration?
>> 
>> On Fri, Nov 30, 2018 at 11:36 AM Jan Mercl <0xj...@gmail.com> wrote:
>>> 
>>> 
>>> 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("%v %v\n", myValue, v)
 }
>>> 
>>> There's no pointer dereference inside the loop. But there's an allocation 
>>> inside the loop, on every iteration, that puts a pointer to a copy of 
>>> myValue into an interface{} that's passed to fmt.Printf. The allocation can 
>>> be probably avoided:
>>> 
>>> myValue := interface{}(*myPtr)
>>> for _, v := range values {
>>>fmt.Printf("%v %v\n", myValue, v)
>>> }
>>> 
>>> But the %v verb handle pointers in many cases well. If that holds for the 
>>> type of *myPtr then simply:
>>> 
>>> for _, v := range values {
>>>fmt.Printf("%v %v\n", myPtr, v)
>>> }
>>> 
>>> is what could be good enough.
>>> 
>>> --
>>> 
>>> -j
>> 
>> 
>> 
>> --
>> R. Mark Volkmann
>> Object Computing, Inc.
>> 
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>> 
>> 
>> 
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>> 
>> 
>> 
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>> 
>> 
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> 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 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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.
For more options, visit https://groups.google.com/d/optout.

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

[robert engels]

Then rewrite it this way


func SomeFunc() {

 count:= 1
 p := 

 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:
> 
> 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
> 
> for … {
>   total += *p
>   foo()
> }
> 
> //jb
> 
>> On 30 Nov 2018, at 19:01, robert engels > > wrote:
>> 
>> 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 count = 1
>>> var p = 
>>> 
>>> 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 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 loop iteration?
 
 On Fri, Nov 30, 2018 at 11:36 AM Jan Mercl <0xj...@gmail.com 
 > wrote:
 
 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("%v %v\n", myValue, v)
 > }
 
 There's no pointer dereference inside the loop. But there's an allocation 
 inside the loop, on every iteration, that puts a pointer to a copy of 
 myValue into an interface{} that's passed to fmt.Printf. The allocation 
 can be probably avoided:
 
 myValue := interface{}(*myPtr)
 for _, v := range values {
 fmt.Printf("%v %v\n", myValue, v)
 }
 
 But the %v verb handle pointers in many cases well. If that holds for the 
 type of *myPtr then simply:
 
 for _, v := range values {
 fmt.Printf("%v %v\n", myPtr, v)
 }
 
 is what could be good enough.
 
 -- 
 -j
 
 
 
 -- 
 R. Mark Volkmann
 Object Computing, Inc.
 
 -- 
 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 
 .
 For more options, visit https://groups.google.com/d/optout 
 .
>>> 
>>> 
>>> -- 
>>> 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 
>>> .
>>> For more options, visit https://groups.google.com/d/optout 
>>> .
>> 
>> 
>> -- 
>> 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 
>> .
>> For more options, visit https://groups.google.com/d/optout 
>> .
> 
> 
> -- 
> 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 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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.
For more options, visit https://groups.google.com/d/optout.

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

[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 pointer aliases:

p:=
q:=

for ... {
   total+=*p
   (*q)++
}

>
> So maybe it’s optimized in
>
> for … {
>   total += *p
> }
>
> but I wouldn’t bet on it in
>
> for … {
>   total += *p
>   foo()
> }
>
> //jb
>
> On 30 Nov 2018, at 19:01, robert engels  wrote:
>
> 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 count = 1
> var p = 
>
> 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 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 
> loop iteration?
>
> On Fri, Nov 30, 2018 at 11:36 AM Jan Mercl <0xj...@gmail.com> wrote:
>>
>>
>> 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("%v %v\n", myValue, v)
>> > }
>>
>> There's no pointer dereference inside the loop. But there's an allocation 
>> inside the loop, on every iteration, that puts a pointer to a copy of 
>> myValue into an interface{} that's passed to fmt.Printf. The allocation can 
>> be probably avoided:
>>
>> myValue := interface{}(*myPtr)
>> for _, v := range values {
>> fmt.Printf("%v %v\n", myValue, v)
>> }
>>
>> But the %v verb handle pointers in many cases well. If that holds for the 
>> type of *myPtr then simply:
>>
>> for _, v := range values {
>> fmt.Printf("%v %v\n", myPtr, v)
>> }
>>
>> is what could be good enough.
>>
>> --
>>
>> -j
>
>
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

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

[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

for … {
  total += *p
  foo()
}

//jb

On 30 Nov 2018, at 19:01, robert engels 
mailto:reng...@ix.netcom.com>> wrote:

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 
mailto:reng...@ix.netcom.com>> wrote:

It’s as simple as:

var count = 1
var p = 

func X() {
 total :=0

 for i:=0; i <100;i++ {
total = total + *p
 }
}

no ?

On Nov 30, 2018, at 11:48 AM, Mark Volkmann 
mailto:r.mark.volkm...@gmail.com>> wrote:

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 loop iteration?

On Fri, Nov 30, 2018 at 11:36 AM Jan Mercl 
<0xj...@gmail.com> wrote:

On Fri, Nov 30, 2018 at 6:16 PM Mark Volkmann 
mailto:r.mark.volkm...@gmail.com>> 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("%v %v\n", myValue, v)
> }

There's no pointer dereference inside the loop. But there's an allocation 
inside the loop, on every iteration, that puts a pointer to a copy of myValue 
into an interface{} that's passed to fmt.Printf. The allocation can be probably 
avoided:

myValue := interface{}(*myPtr)
for _, v := range values {
fmt.Printf("%v %v\n", myValue, v)
}

But the %v verb handle pointers in many cases well. If that holds for the type 
of *myPtr then simply:

for _, v := range values {
fmt.Printf("%v %v\n", myPtr, v)
}

is what could be good enough.

--

-j


--
R. Mark Volkmann
Object Computing, Inc.

--
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.
For more options, visit https://groups.google.com/d/optout.


--
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.
For more options, visit https://groups.google.com/d/optout.


--
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.
For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

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

[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 count = 1
> var p = 
> 
> 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 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 
>> loop iteration?
>> 
>> On Fri, Nov 30, 2018 at 11:36 AM Jan Mercl <0xj...@gmail.com 
>> > wrote:
>> 
>> 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("%v %v\n", myValue, v)
>> > }
>> 
>> There's no pointer dereference inside the loop. But there's an allocation 
>> inside the loop, on every iteration, that puts a pointer to a copy of 
>> myValue into an interface{} that's passed to fmt.Printf. The allocation can 
>> be probably avoided:
>> 
>> myValue := interface{}(*myPtr)
>> for _, v := range values {
>> fmt.Printf("%v %v\n", myValue, v)
>> }
>> 
>> But the %v verb handle pointers in many cases well. If that holds for the 
>> type of *myPtr then simply:
>> 
>> for _, v := range values {
>> fmt.Printf("%v %v\n", myPtr, v)
>> }
>> 
>> is what could be good enough.
>> 
>> -- 
>> -j
>> 
>> 
>> 
>> -- 
>> R. Mark Volkmann
>> Object Computing, Inc.
>> 
>> -- 
>> 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 
>> .
>> For more options, visit https://groups.google.com/d/optout 
>> .
> 
> 
> -- 
> 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 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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.
For more options, visit https://groups.google.com/d/optout.

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

[robert engels]

It’s as simple as:

var count = 1
var p = 

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 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 
> loop iteration?
> 
> On Fri, Nov 30, 2018 at 11:36 AM Jan Mercl <0xj...@gmail.com 
> > wrote:
> 
> 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("%v %v\n", myValue, v)
> > }
> 
> There's no pointer dereference inside the loop. But there's an allocation 
> inside the loop, on every iteration, that puts a pointer to a copy of myValue 
> into an interface{} that's passed to fmt.Printf. The allocation can be 
> probably avoided:
> 
> myValue := interface{}(*myPtr)
> for _, v := range values {
> fmt.Printf("%v %v\n", myValue, v)
> }
> 
> But the %v verb handle pointers in many cases well. If that holds for the 
> type of *myPtr then simply:
> 
> for _, v := range values {
> fmt.Printf("%v %v\n", myPtr, v)
> }
> 
> is what could be good enough.
> 
> -- 
> -j
> 
> 
> 
> -- 
> R. Mark Volkmann
> Object Computing, Inc.
> 
> -- 
> 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 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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.
For more options, visit https://groups.google.com/d/optout.

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

[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 loop iteration?

On Fri, Nov 30, 2018 at 11:36 AM Jan Mercl <0xj...@gmail.com> wrote:

>
> 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("%v %v\n", myValue, v)
> > }
>
> There's no pointer dereference inside the loop. But there's an allocation
> inside the loop, on every iteration, that puts a pointer to a copy of
> myValue into an interface{} that's passed to fmt.Printf. The allocation can
> be probably avoided:
>
> myValue := interface{}(*myPtr)
> for _, v := range values {
> fmt.Printf("%v %v\n", myValue, v)
> }
>
> But the %v verb handle pointers in many cases well. If that holds for the
> type of *myPtr then simply:
>
> for _, v := range values {
> fmt.Printf("%v %v\n", myPtr, v)
> }
>
> is what could be good enough.
>
> --
>
> -j
>


-- 
R. Mark Volkmann
Object Computing, Inc.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

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

[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("%v %v\n", myValue, v)
> }

There's no pointer dereference inside the loop. But there's an allocation
inside the loop, on every iteration, that puts a pointer to a copy of
myValue into an interface{} that's passed to fmt.Printf. The allocation can
be probably avoided:

myValue := interface{}(*myPtr)
for _, v := range values {
fmt.Printf("%v %v\n", myValue, v)
}

But the %v verb handle pointers in many cases well. If that holds for the
type of *myPtr then simply:

for _, v := range values {
fmt.Printf("%v %v\n", myPtr, v)
}

is what could be good enough.

-- 

-j

-- 
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.
For more options, visit https://groups.google.com/d/optout.