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?
The Go Compiler Needs to Be Smarter
11–20 of 119 posts
Re: The Go Compiler Needs to Be Smarter
#12Sure, 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…
Well but that's not what's at play here
Inlining basic functions shouldn't be surprising to anyone since the 80's? 90's? Unless you compile with -O0 or has a good reason to not inline it. Compilers are usually good at it.
Same with the runtime checking every time if a given processor flag exists. What I suppose most runtimes do is replace a function pointer or have a function shin then add a call dynamically to the correct function. Not calling a function repeatedly to check if a processor feature exists.
Re: The Go Compiler Needs to Be Smarter
#13It will be a whole lot smarter on June 8th at 7am pacific, https://www.youtube.com/watch?v=Dq0WFigax_c
I believe it when I see it on https://golang.org/doc/devel/release.html
Until then, it is just yet another "we are working on it" like so many that have come up during the last 10 years.
Re: The Go Compiler Needs to Be Smarter
#14Sure, 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…
> Go is a "principle of least surprise" language, based on a vision of simplicity for C that hasn't existed among actual C implementations (outside of maybe Plan 9) for decades now. It's yet more suckless idiocy
Have you considered that this Go opinion might not be “idiocy” but desirable qualities in some use cases?
It seems quite inappropriate to bash on Go for realising a vision that solves such a use case, in turn assuming no such use case exists, just as it is inappropriate to vilify Ruby or Python for for having a very dynamic object model and method calling/message passing, witch results in non-optimisable call paths because they have to be resolved every single time.
Go’s consistency, reliability, and ease in debugging and exploring is definitely a really good feature that I gladly trade a few microseconds for.
Re: The Go Compiler Needs to Be Smarter
#15Go mostly has been only picking up easy wins so far. I haven't seen any attempt to go further than that. Which is fair strategy for first few years since everything comes with a cost. But, people now expect to see more obviously specially the more it's being compared to more sophisticated languages and compilers.
Re: The Go Compiler Needs to Be Smarter
#16The 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 unacceptable to the core Go team.
Re: The Go Compiler Needs to Be Smarter
#17I find it hard to fathom that many programming languages still don't use partial evaluation. That a popular language avoids inlining is even beyond that.
Inlining us hard to do in ways that makes sure you always produce the optimal code, but simple conservative inlining is probably among the simplest and most efficient optimisations you can do.
Edit: one of my favourite quotes is about the hardships of the heuristics of inliners: "I don't know how many of you have tried to write a good inliner. It is like barely being able to restrain a rabid dog on a leash".
I probably mangled that, but originally it is a quote by Andy Wingo when talking about the improved optimisations of guile 2.2.
Re: The Go Compiler Needs to Be Smarter
#18The 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…
Even Java and .NET do better on auto vectorization.
Intel has recently published an article on using Go, their advice?
Manually use cgo or Go Assembly for the AVX.
Re: The Go Compiler Needs to Be Smarter
#19I find it hard to fathom that many programming languages still don't use partial evaluation. That a popular language avoids inlining is even beyond that. Inlining us hard to do in ways that makes sure you always produce the optimal code, but simple conservative inlining is probably among the simplest and most efficient optimisations you can do. Edit: one of my favourite quotes is about the hardships of the heuristics…
Go does inlining and their inlining heuristic has been tweaked over time.
Re: The Go Compiler Needs to Be Smarter
#20Another pain point in Go I vaguely recall is that functions written in assembly are never inlined, so you always pay some penalty for using such functions (this may have changed in a more recent version of Go).