News for hackers. Stuff that matters.

A comment on Benefits of named return values in Go. Parent comment

Re:Benefits of named return values in Go by pcwalton on Friday June 30, 2017 @03:14AM (#14669090)
Just for what it's worth, the way I'd fix that problem in the compiler would be to implement dead store elimination via global value numbering. With trivial alias analysis, the compiler would be able to detect that the result of the "duffzero" instruction (which I assume is a memset) is always killed by the "duffcopy" instructions and would eliminate it.

See this article for how it's done in LLVM: http://blog.llvm.org/2009/12/introduction-to-load-eliminatio...

[ Parent | on HN ]
Re:Benefits of named return values in Go by heythere124 on Friday June 30, 2017 @07:02AM (#14669841)
Not my area of expertise and it is yours, but if you eliminate a zero instruction before a copy instruction how can you be sure that doesn't affect other threads?

  var x Int
  // Pass x to a thread by reference
  x = 0
  time.Sleep(1000)
  x = 1
[ Parent | on HN ]
Re:Benefits of named return values in Go by the8472 on Friday June 30, 2017 @08:05AM (#14670168)
How can you be sure that the other threads ever see it in time? they might be suspended for a whole second because a HDD needs to spin up or something like that.

So threads never seeing the value is already a valid outcome, so the compiler might as well always do that.

[ Parent | on HN ]
Re:Benefits of named return values in Go by heythere124 on Friday June 30, 2017 @08:18AM (#14670228)
time.Sleep(1000) could be replaced with a real syncing mechanism of some kind -- it's only for illustration.
[ Parent | on HN ]
Re:Benefits of named return values in Go by the8472 on Friday June 30, 2017 @12:46PM (#14671900)
a real syncing mechanism would introduce compiler barriers that prevent such an optimization.
[ Parent | on HN ]
Re:Benefits of named return values in Go by Filligree on Friday June 30, 2017 @07:59AM (#14670136)
The answer to that one would be to embed thread-safety in the type system, aka. Rust.

For languages with less sophisticated type systems you get a choice between inefficiency (Go), or complicated rules which state that the programmer is wrong for coding that way (C).

[ Parent | on HN ]
Re:Benefits of named return values in Go by heythere124 on Friday June 30, 2017 @08:25AM (#14670263)
Your "solution" is possible in many languages. It's just to give threads complete ownership of data they use. It doesn't require a special type system.

In general I don't think Rust actually adds much abstraction that isn't already in say Python. What it does is enforce tight constraints.

[ Parent | on HN ]
Re:Benefits of named return values in Go by Filligree on Friday June 30, 2017 @09:19AM (#14670496)
The constraints are important. They're what let you code safely, and also give the compiler the ability to optimize better.
[ Parent | on HN ]
Re:Benefits of named return values in Go by heythere124 on Friday June 30, 2017 @10:09AM (#14670806)
Not sure those optimisations are worth much. And it's only safety by forcing lowest common denominator code and making you justify everything to a dumb compiler. Rust serves a niche, but it is a tight niche IMO.
[ Parent | on HN ]
Re:Benefits of named return values in Go by pcwalton on Friday June 30, 2017 @12:44PM (#14671889)
Aliasing info is hugely important in optimization. In fact, it's needed to solve this very bug.

Aliasing info is, fundamentally, what allows Rust to have memory safety without GC.

[ Parent | on HN ]
Re:Benefits of named return values in Go by pcwalton on Friday June 30, 2017 @11:55AM (#14671527)
The memory dependence analysis must prove the memory is unaliased, which ensures among other things that no other thread can have a reference to it. Presumably in Go return pointers are guaranteed to be unaliased.
[ Parent | on HN ]