The Go Compiler Needs to Be Smarter • Hacker News Board

Re: The Go Compiler Needs to Be Smarter

#81

Post by fluffything » Fri, Jun 05, 2020, 2:13 PM UTC

dgellow wrote: post #8

bitwize wrote: post #3

Sure, if your goal is to build a compiler that outputs the fastest possible code. If your goal is to apply the "principle of least surprise" to the generated machine code, then that eliminates or constrains most interesting optimizations, including procedure inlining, dead code elision, and compile-time evaluation. Go is a "principle of least surprise" language, based on a vision of simplicity for C that hasn't exist…

Suckless is promoting C99 and disregards anything with a GC. https://suckless.org/coding_style/

I hope they at least use C11 atomics, or only write single-threaded single-process systems.

Re: The Go Compiler Needs to Be Smarter

#82

Post by Touche » Fri, Jun 05, 2020, 2:14 PM UTC

q3k wrote: post #40

Does it really, though? Go really isn't meant for number crunching, or any CPU-bound code, really. I think it's just fine for a language to not strive to emit the fastest possible code. I don't mind having an ecosystem where build times are fast in return for less optimized code. We already have plenty of languages that do the opposite (Rust, C++, Haskell, ...), and I would personally hate to see Go's compilation/lin…

Why am I using a language with pointers if it doesn't care about being fast?

Another problem with not having a smart compiler is the gigantic binaries it produces. For wasm, an officially supported target, this makes it a non-starter.

Re: The Go Compiler Needs to Be Smarter

#83

Post by Thaxll » Fri, Jun 05, 2020, 2:15 PM UTC

bjoli wrote: post #32

kjksf wrote: post #19

Earlier quoted context omitted.

Go does inlining and their inlining heuristic has been tweaked over time.

The example in the article is a typical function where I would expect inlining. Overly shy seems almost like an understatement.

You can see the reason actually:

  go build -gcflags="-m -m" .
  # _/tmp/inline
  ./main.go:7:6: cannot inline sum: unhandled op RANGE
  ./main.go:15:6: can inline fun as: func() uint64 { x := 
  []uint64 literal; return sum(x) }
  ./main.go:3:6: can inline main as: func() { _ = fun() }
  ./main.go:4:9: inlining call to fun func() uint64 { x 
  := []uint64 literal; return sum(x) }
  ./main.go:7:10: sum x does not escape
  ./main.go:4:9: main []uint64 literal does not escape
  ./main.go:16:15: fun []uint64 literal does not escape

 package main

 func main() {
  _ = fun()
 }

 func sum(x []uint64) uint64 {
  var sum = uint64(0)
  for _, v := range x {
   sum += v
  }
  return sum
 }

 func fun() uint64 {
  x := []uint64{10, 20, 30}
  return sum(x)
 }

Go does not inline range operation.

Re: The Go Compiler Needs to Be Smarter

#84

Post by cies » Fri, Jun 05, 2020, 2:15 PM UTC

Thaxll wrote: post #77

q3k wrote: post #40

Does it really, though? Go really isn't meant for number crunching, or any CPU-bound code, really. I think it's just fine for a language to not strive to emit the fastest possible code. I don't mind having an ecosystem where build times are fast in return for less optimized code. We already have plenty of languages that do the opposite (Rust, C++, Haskell, ...), and I would personally hate to see Go's compilation/lin…

Hmm I disagree, Go is a language that should have workload that is CPU bound, Go is not Python or Ruby it's more C++ in that case. It can do heavy computation, I think it's just a balance of compiler optimization vs compile time.

Go is a Google project. You may disagree all you like but it's their project and hence their priorities.

I would have loved for Go not to copy in the "null mistake", to have generics available to all and to have proper sum types built in. But it does not and Google is not keen on fixing this. So I look elsewhere: Rust, Kotlin, Reason/OCaml, ...

Re: The Go Compiler Needs to Be Smarter

#85

Post by q3k » Fri, Jun 05, 2020, 2:18 PM UTC

Touche wrote: post #82

q3k wrote: post #40

Does it really, though? Go really isn't meant for number crunching, or any CPU-bound code, really. I think it's just fine for a language to not strive to emit the fastest possible code. I don't mind having an ecosystem where build times are fast in return for less optimized code. We already have plenty of languages that do the opposite (Rust, C++, Haskell, ...), and I would personally hate to see Go's compilation/lin…

Why am I using a language with pointers if it doesn't care about being fast? Another problem with not having a smart compiler is the gigantic binaries it produces. For wasm, an officially supported target, this makes it a non-starter.

> Why am I using a language with pointers if it doesn't care about being fast?

Because, I assume, you want to differentiate between pass-by-value and pass-by-reference - and pointers are a familiar, simple (if not simplistic) way of expressing that.

Re: The Go Compiler Needs to Be Smarter

#86

Post by geodel » Fri, Jun 05, 2020, 2:19 PM UTC

vips7L wrote: post #50

rob74 wrote: post #43

Earlier quoted context omitted.

More verbose than Java? Is that even possible?

I honestly don't understand how anyone thinks go is LESS verbose than java. Go is full of manually iteration loops and doesn't have anyform of pattern matching/switch expressions.

Well I agree and disagree. Agree in sense many individual expressions are same or more verbose in Go. Disagree in sense at a project level for roughly same amount of functionality idiomatic Java take at least ~5 times the code and directories than idiomatic Go code.

Re: The Go Compiler Needs to Be Smarter

#87

Post by wwarner » Fri, Jun 05, 2020, 2:27 PM UTC

With its well defined AST, I think Go can "easily" accommodate optimizations as described, but obviously at the expense of compililation time. And I gotta tell you that keeping compile times down is the more important optimization for me. However, I happily add automated scans for safety and correctness into my release candidates, and I would gladly pay for optimizations at that point. As long as I can test rapidly with the knowledge that I can add an "-O3" flag just before release would be a perfect compromise for me.

Re: The Go Compiler Needs to Be Smarter

#88

Post by remus » Fri, Jun 05, 2020, 2:57 PM UTC

Touche wrote: post #82

q3k wrote: post #40

Does it really, though? Go really isn't meant for number crunching, or any CPU-bound code, really. I think it's just fine for a language to not strive to emit the fastest possible code. I don't mind having an ecosystem where build times are fast in return for less optimized code. We already have plenty of languages that do the opposite (Rust, C++, Haskell, ...), and I would personally hate to see Go's compilation/lin…

Why am I using a language with pointers if it doesn't care about being fast? Another problem with not having a smart compiler is the gigantic binaries it produces. For wasm, an officially supported target, this makes it a non-starter.

> Why am I using a language with pointers if it doesn't care about being fast?

I think there's a big difference between 'I dont care about speed' and 'fast enough'. Go sits pretty firmly in the 'fast enough' category for a lot of people, but of course if you lose sight of speed concerns entirely it'll quickly slow down and then won't be fast enough for a lot of people.

Re: The Go Compiler Needs to Be Smarter

#89

Post by pjmlp » Fri, Jun 05, 2020, 3:05 PM UTC

hu3 wrote: post #72

pjmlp wrote: post #70

Earlier quoted context omitted.

Since it is so hard for you to use Google, here you go: https://cr.openjdk.java.net/~vlivanov/talks/2017_Vectorizati... https://www.codeproject.com/Articles/1223361/Benchmarking-NE... https://clearlinux.org/blogs-news/performant-containerized-g... Now go play with your facts.

Intel doesn't directly advice for neither of the 3 methods. It simply states that handcrafting assembly code is faster which is always the case anyway. So everybody can see how dishonest pjmlp is towards Go, here is their interpretation of Intel's conclusion: > Intel has recently published an article on using Go, their advice? Manually use cgo or Go Assembly for the AVX. . . And here is the actual Intel conclusion fr…

Please enlighten us where does Intel describe how to do auto-vectorization with Go, because writing Go Assembly, using cgo writing C intrinsics by hand, or link to a third party library hand optimized doesn't look very automatic to me.

Like I said, play with facts if that makes you feel good.

Re: The Go Compiler Needs to Be Smarter

#90

Post by kevindong » Fri, Jun 05, 2020, 3:12 PM UTC

Touche wrote: post #82

q3k wrote: post #40

Does it really, though? Go really isn't meant for number crunching, or any CPU-bound code, really. I think it's just fine for a language to not strive to emit the fastest possible code. I don't mind having an ecosystem where build times are fast in return for less optimized code. We already have plenty of languages that do the opposite (Rust, C++, Haskell, ...), and I would personally hate to see Go's compilation/lin…

Why am I using a language with pointers if it doesn't care about being fast? Another problem with not having a smart compiler is the gigantic binaries it produces. For wasm, an officially supported target, this makes it a non-starter.

I think Go does care about being fast, but only to a degree. Having the compiled binary being as fast as possible isn't actually one of the listed pain points that Go was designed to solve [0].

[0]: https://talks.golang.org/2012/splash.article#TOC_4.