Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Go Compiler Needs to Be Smarter

lemire.me

Post reply on HN
Print view View original

91–100 of 119 posts

Re: The Go Compiler Needs to Be Smarter

#91

Post by cogman10 »

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 makes sense to integrate a "release" build which targets LLVM? IDK. But I do know that so long as compilation speed is a major goal for the language the you simply won't see optimizations being seriously considered.

Re: The Go Compiler Needs to Be Smarter

#92

Post by uryga »

Thaxll wrote: post #83
bjoli wrote: post #32

Earlier quoted context omitted.

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

> Go does not inline range operation.

do you know why?

[not super familiar with Go, just curious]

Re: The Go Compiler Needs to Be Smarter

#93

Post by zamadatix »

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?

Re: The Go Compiler Needs to Be Smarter

#94

Post by jerf »

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.

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 implementation on.

My rule of thumb for Go performance is that's roughly 2-3x slower that C/C++. While human loss aversion is probably kicking in and making that sound horrible, from an engineering perspective, it's likely you'll not notice it, speaking broadly from my position of ignorance. However, if you do have your code deployed to places that are routinely running the CPU at 50%+ all the time in your C++ code (as opposed to DB wait or whatever), and you are not interested in investing in more hardware, I wouldn't even consider switching to Go.

Re: The Go Compiler Needs to Be Smarter

#95

Post by poorman »

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…

That's understandable. There's a large cost to doing cgo calls. Not to mention you get into a weird situation where the cgo calls take too long to execute and the Go scheduler/pacer can make things even worse by suspending execution.

Re: The Go Compiler Needs to Be Smarter

#96

Post by jerf »

gautamcgoel wrote: post #16

The optimization I care about most is vectorization. A lot of ML and data science basically boils down to numerical linear algebra and optimization; vectorization is the key optimization for these kinds of problems. I bet if Go got a better autovectorizer it would compare more favorably against languages like Rust and C++ for numerical tasks. The trade-off, of course, is longer compile times, which I suspect will be…

I like Go. I use it a lot. I've been called a Go shill on HN.

And I seriously do not understand the appeal of trying to use Go for heavily-vectorized code. The ASM support is sufficient for encryption kernels and some lightweight additions like bigints, but if you're writing the kind of code where you want the compiler to autovectorize a lot of math operations, why would you want to write that in Go at all? Why start from scratch in a language with designers that may not actively hate your use case, but certainly don't care much about it, when you can work in a language+runtime+library environment that deeply cares about that use case?

If I for some reason had a task like this handed to me at work, I'd drop Go in a heartbeat and go get something reasonable for the task.

Go will never be good for numeric or mathematical tasks. Those things involve richer type systems than Go has, or weaker type systems (dynamic types); Go's type system is arguably pessimal for this use case, being both too strong and too weak at the same time. Even if Go grows generics, they are very likely to still not be what a numeric system is looking for. Rich numeric types put a lot of strain on type systems (rather than being the easiest case which I think some people's intuitions might suggest, they are the worst case), and Go's type system is simply never going to be complexified enough for what you'd want in a numeric/mathematical system because it would be directly at odds with their stated use cases.

It isn't even that Go is kind of weak on this one point, but if you fixed it, you'd have a great numerical language... the whole language is shot through with little things here and there that work against numeric code, the explicitly-stated desire for a fast compiler that doesn't do much optimization probably being the most notable other problem. Making Go an even decent numerical language would pretty much involve a full fork of it.

Re: The Go Compiler Needs to Be Smarter

#97

Post by hu3 »

pjmlp wrote: post #89
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…

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.

Who said it needs to support vectorization natively? It's not what Go was created for so it's fine to exist as a library or assembly code.

Go has stricter goals than Java or .NET. So comparing them favorably is like saying a Corolla sucks because it lacks features present in a heavy duty truck.

Again, Intel's article doesn't advocate for any method. It just presents results. Anyone can read the article and conclude for themselves that you're extrapolating to the worse interpretation possible as usual.

Re: The Go Compiler Needs to Be Smarter

#98

Post by bfrog »

JTenerife wrote: post #35

No benchmarks or any other numbers. I wonder how much faster some typical Go code (some CLIs, Hugo or webservices) will run? Around 1%, 5% or 10%? The Go compiler doesn't need to be smarter for Go's usecase. If it can be made smarter, fine. For best possible performance look at C/C++ or Rust.

It's too bad Go has poor performance calling C functions, if it didn't I think most issues with the language could be worked around.

Re: The Go Compiler Needs to Be Smarter

#99

Post by BubRoss »

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…

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.

Re: The Go Compiler Needs to Be Smarter

#100

Post by hu3 »

poorman wrote: post #95
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…

That's understandable. There's a large cost to doing cgo calls. Not to mention you get into a weird situation where the cgo calls take too long to execute and the Go scheduler/pacer can make things even worse by suspending execution.

True. These are valid concerns one should keep in mind when using cgo.
Post reply on HN