Does the compiler optimize non-mutated values?

[Matt Sherman]

Browsing around the Swift docs, I see that they encourage the use of immutable values in let. Nice habit. There are two things that comes to mind with this.

First, it encourages the dev to make deliberate design decisions about mutability vs not. Second, immutable values are an opportunity for compiler optimizations, yes?

So even though Go doesn't do immutable, per se, the compiler can know if a (non-exported) value is mutated in its package. If it is provably not mutated, it's therefore equivalent to immutable.

Am curious if the Go compiler(s) contain such logic or optimizations.

[⚛]

There is no such logic in the Go compiler(s).

On Thursday, June 5, 2014 7:49:37 PM UTC+2, Matt Sherman wrote:

Browsing around the Swift docs, I see that they encourage the use of immutable values in let. Nice habit. There are two things that comes to mind with this.

First, it encourages the dev to make deliberate design decisions about mutability vs not. Second, immutable values are an opportunity for compiler optimizations, yes?

- I agree that, in theory, immutable values can be an opportunity for compiler optimizations. The hard part is how in general to determine that for example specializing code according to a regular expression (which is immutable once it is compiled) is such an opportunity.

- A Go compiler may as the first step in this direction attempt to specialize code according to the string constants and value types passed to fmt.Printf.

[Ian Lance Taylor]

On Thu, Jun 5, 2014 at 10:49 AM, Matt Sherman <mwsh...@gmail.com> wrote:
>
> So even though Go doesn't do immutable, per se, the compiler can know if a
> (non-exported) value is mutated in its package. If it is provably not
> mutated, it's therefore equivalent to immutable.
>
> Am curious if the Go compiler(s) contain such logic or optimizations.

The gccgo compiler does this in some cases.

For example, given a package whose entire contents is this:

var i = 4

func F() int {
return i
}

gccgo will compile F() into "return 4".


Ian

[⚛]

I am assuming that gccgo will disable this optimization as soon as there is a write into memory and the write is missing contextual information. Such writes could be easily found in all packages. Is this correct?

[andrewc...@gmail.com]

Because of the way pointers are more restricted, the compiler can probably make more assumptions about memory aliasing which means less variables have to be reloaded whenever there is a memory write. This is probably similar to any compiler optimization that is done from declaring a variable as immutable.

[Ian Lance Taylor]

No. In the above nothing sets i and nothing takes the address of i.
There is no valid way to construct a pointer that will change i.
Gccgo does not consider the possibility of using unsafe.Pointer to
randomly mutate memory. That is intentional.

Ian

[Matt Sherman]

I wonder if provable immutability would provide benefits for synchronizing reads, which is to say, the burden of ordering reads & writes is removed.

[andrewc...@gmail.com]

On Friday, June 6, 2014 10:39:51 AM UTC+12, Matt Sherman wrote:

I wonder if provable immutability would provide benefits for synchronizing reads, which is to say, the burden of ordering reads & writes is removed.

 
Yes it would. There are no writes so you don't need to order them. Immutable variables would only be visible in the constructing thread until it leaks a reference :).
Without explicit constructors as part of the language, some thought would be needed to decide exactly the semantics and depth of immutable structs, variables, and references.
e.g. Perhaps only &{} style initializers would be allowed for immutable structs and perhaps a special keyword would be needed to declare an immutable reference.

I've played with clojure and its immutable data structures are pretty nifty. I don't imagine any immutable types will be added to Golang at least until Go 2

[Matt Sherman]

It also occurs to me that values could be interned: http://clipperhouse.com/2014/06/05/de-facto-immutability/