The Go Compiler Needs to Be Smarter • Hacker News Board

Re: The Go Compiler Needs to Be Smarter

#101

Post by sanderjd » Fri, Jun 05, 2020, 4:05 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.

My take on this has long been that Go created a lot of confusion by initially selling itself as a better C++ when it is actually much closer to a better Python (outside of the data science use cases).

Edit to add: Or a better / easier to deploy / less reviled / hipper Java.

Go is a good and valuable language, but I think perhaps more than any language I know of, a lot of people go into it expecting it to be something that it is not.

Re: The Go Compiler Needs to Be Smarter

#102

Post by Thaxll » Fri, Jun 05, 2020, 4:09 PM UTC

uryga wrote: post #92

Thaxll wrote: post #83

Earlier quoted context omitted.

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: m…

> Go does not inline range operation. do you know why? [not super familiar with Go, just curious]

I'm not sure I think it's just a current limitation: https://github.com/golang/go/wiki/CompilerOptimizations#func...

They do improve the compiler every release, so we might see some of those operations get inlined in the future.

More information there: https://github.com/golang/go/blob/master/src/cmd/compile/int...

Re: The Go Compiler Needs to Be Smarter

#103

Post by jjice » Fri, Jun 05, 2020, 4:49 PM UTC

alharith wrote: post #74

_wldu wrote: post #62

"I do not mind that Go lacks exceptions or generics. These features are often overrated." I agree 100%. I've used them both in C++. I hope Go never gets them.

Generics, I would certainly be ecstatic for if it was done in a way that is novel and feels Go-like , so not Java or C# or C++'s implementations. This has certainly been the stance of the Go team since the beginning of time. It has never been "anti-generics" it's always been "we've studied all the generics implementations out there, and didn't feel like any one of them were good enough, so rather than shoehorn them i…

What's wrong with the way that Java, C# a, and C++ handle generics? I see this complaint fairly regularly, but I was never sure why. Is it how the compiler handles it, or how the language defines it that is the reason for this dislike? Genuine curiosity.

Re: The Go Compiler Needs to Be Smarter

#104

Post by pstuart » Fri, Jun 05, 2020, 5:25 PM UTC

Cthulhu_ wrote: post #76

ozo9Caej wrote: post #33

Earlier quoted context omitted.

Same here. Go is now my daily driver and main language, and I'm perfectly satisfied with it. Quite the opposite of expecting more, I'm very fearful on what may change or be added in go-2 (which is actually a reason why I'm currently learning C, just in case).

Personally, if Go takes a bad turn, I'm likely to just go back to JVM languages. Not Scala though, they went overboard with that one.

Disclaimer: I'm a Go fanboy so I'm biased.

> if Go takes a bad turn

The conservative nature of the Go team seems to recognize this worry. It's been bashed from the beginning for no generics but they are working on it. They just haven't found something that "feels right".

Of course there's just no pleasing all the people all the time.

Re: The Go Compiler Needs to Be Smarter

#105

Post by cogman10 » Fri, Jun 05, 2020, 5:43 PM UTC

zamadatix wrote: post #93

cogman10 wrote: post #91

I may have missed it, but this discussion seems to be lacking a key motivation of go. That is, the go devs have preferred a fast compiler over fast code output. I have a hard time imagining them adding a bunch of optimizations around code generation when those optimizations will almost certainly: * Slow down compile times * Increase compiler complexity * Be worse than what something like LLVM would produce. Maybe it…

Did you catch the note at the end about how gccgo is slower? If so how does pivoting to LLVM solve the issues seen there?

You can read about the why here.

https://stackoverflow.com/questions/25811445/what-are-the-pr...

The short answer is that there are optimizations that the GC is doing which gccgo is not doing.

The long answer is that gc will do escape analysis which can avoid allocating on the heap, gccgo doesn't do that.

Why might LLVM be better suited? Primarily because the framework also supports JIT and has efforts from the likes of Azul to make their JVM faster. Most optimizations that would benefit Java will benefit go.

https://llvm.org/devmtg/2017-10/slides/Reames-FalconKeynote....

Re: The Go Compiler Needs to Be Smarter

#106

Post by dirtydroog » Fri, Jun 05, 2020, 6:58 PM UTC

jerf wrote: post #94

dirtydroog wrote: post #57

Earlier quoted context omitted.

What are your usecases, if you don't mind me asking? I am considering replacing our HTTP-heavy processes currently written in C++ with Go. However, after reading this thread I'm not so sure. Compilation time isn't that big of an issue for us, but having a simpler way of doing networking would be a win. I can't tell if that ease of use would be trumped by poor performance.

It isn't clear to me you're looking at a clear win there. If you do want to try it out, I recommend the strangler pattern: https://docs.microsoft.com/en-us/azure/architecture/patterns... With HTTP it's really easy to rewrite one URL at a time. You just need some way to proxy things around, nginx if nothing else, and then you can swap things as you go along, so you can pick and choose which URLs to test the Go impleme…

It's mainly binary to JSON conversion, and firing that out over HTTP a few thousand times a second. That's the only IO. Goroutines look very interesting, and as I said, ASIO (C++ async networking) is a real pain to work with. But there are latency requirements here. Something that previously took 1ms cannot now take 10ms.

Re: The Go Compiler Needs to Be Smarter

#107

Post by yencabulator » Fri, Jun 05, 2020, 10:22 PM UTC

dirtydroog wrote: post #57

gizzlon wrote: post #28

Earlier quoted context omitted.

> But, people now expect to see more obviously [..] I don't. I mean, yay for improvements, but it's already working great for my usecases.

What are your usecases, if you don't mind me asking? I am considering replacing our HTTP-heavy processes currently written in C++ with Go. However, after reading this thread I'm not so sure. Compilation time isn't that big of an issue for us, but having a simpler way of doing networking would be a win. I can't tell if that ease of use would be trumped by poor performance.

Here's the classic story about replacing a C++ HTTP server with a "slower" Go one: https://talks.golang.org/2013/oscon-dl.slide

Mind you, in 2013 the Go compiler was at go1.1, and had practically no optimizers at all.

Re: The Go Compiler Needs to Be Smarter

#108

Post by sitkack » Sat, Jun 06, 2020, 2:08 AM UTC

sk0g wrote: post #11

sitkack wrote: post #7

It will be a whole lot smarter on June 8th at 7am pacific, https://www.youtube.com/watch?v=Dq0WFigax_c

Not for end users of the language for a good while, right?

Scroll down to "run in webassembly" and you can try out the prototype.

https://blog.tempus-ex.com/generics-in-go-how-they-work-and-...

Re: The Go Compiler Needs to Be Smarter

#109

Post by nirui » Sat, Jun 06, 2020, 3:31 AM 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…

I write Go and a bit Rust. I don't think compile time could be a huge problem, because:

1. There are ways to reduce it. For example incremental compiling, only recompile what's needed.

2. Many programmers already using CI when they're test/deploy/release their projects. And CI itself takes a long time to initialize and execute, basically throws away almost all the benefits of a fast compiler.

3. Let's don't forget the compiler could have different compile mode (Debug/Release mode), if Go wants to introduce it of course.

Re: The Go Compiler Needs to Be Smarter

#110

Post by pjmlp » Sat, Jun 06, 2020, 2:55 PM UTC

BubRoss wrote: post #99

hu3 wrote: post #72

Earlier quoted context omitted.

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…

Wait until a webasm thread comes around again and you'll see a real rabbit hole of extreme conflation, false claims, bad faith arguments and willful ignoring of facts and evidence.

Glad not to disappoint the accolades of WebAssembly knighthood.