On Fri, Nov 30, 2018 at 11:09 AM Jakob Borg <ja...@kastelo.net> 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:=&value
q:=&value
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 <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 <reng...@ix.netcom.com> wrote:
>
> It’s as simple as:
>
> var count = 1
> var p = &count
>
> func X() {
> total :=0
>
> for i:=0; i <1000000;i++ {
> total = total + *p
> }
> }
>
> no ?
>
> On Nov 30, 2018, at 11:48 AM, Mark Volkmann <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 <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.
--
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.
