This is a very interesting at a time when we're seeing what we can replace C++ with. (yes, rusticles, I know rust exists)
I believe the correct term is 'rustaceans'.
The Go Compiler Needs to Be Smarter
31–40 of 119 posts
Re: The Go Compiler Needs to Be Smarter
#32I 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.
The example in the article is a typical function where I would expect inlining. Overly shy seems almost like an understatement.
Re: The Go Compiler Needs to Be Smarter
#33Go 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.
> 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.
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).
Re: The Go Compiler Needs to Be Smarter
#34A frustrating thing about inlining in Go is that there's a fairly arbitrary cost model and you sometimes end up fighting it (lookup George Tankersley's talks on YouTube). There have been tons of discussions about whether or not it should be user configurable, if inlining hints should happen at the call sites or function definitions etc. It's quite a nice discussion that helps people understand the toolchain. It also…
Those optimizations could be taken advantage of via gccgo.
Also many other languages keep having backend issues, because those optimizations are too focused on C and C++ code semantics.
Re: The Go Compiler Needs to Be Smarter
#35No 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.
Re: The Go Compiler Needs to Be Smarter
#36Correct me if I'm wrong but comparing Go against Swift, C, C++, and Rust isn't really fair since one of Go's goals is compilation speed, in which it seems to shine against these other languages. From what I understand, you're going to trade performance against compilation speed, and Go is on the opposite side of these choices compared to the other languages.
We could compare it with D, Ada, Object Pascal or Delphi, and it would lose on compilation speed, language features and quality of generated code.
Re: The Go Compiler Needs to Be Smarter
#37The 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…
Well it sucks for now, but Gorgonia and Gonum has a bunch of vectorized libraries for deep learning related use cases - they are "hand written" kernels (in actual fact generated by gcc -O3) This kernels method of doing things makes it easy to upgrade code. Check it out: https://github.com/gorgonia/vecf64
Given how brittle autovectorizers can be (small changes to the code preventing the heuristic from firing), that is pretty much the only reliably fast way to write such a library currently, and perhaps indefinitely.
Re: The Go Compiler Needs to Be Smarter
#38Earlier quoted context omitted.
Suckless is promoting C99 and disregards anything with a GC. https://suckless.org/coding_style/
> All variable declarations at top of block. And they say they want their C code to suck less ? Why voluntarily open the door to read-before-write undefined-behaviour? The lifetime of a local should be as short as it reasonably can be.
Doesn't C99 warn you if you make such mistakes?
Re: The Go Compiler Needs to Be Smarter
#39Earlier quoted context omitted.
Suckless is promoting C99 and disregards anything with a GC. https://suckless.org/coding_style/
> All variable declarations at top of block. And they say they want their C code to suck less ? Why voluntarily open the door to read-before-write undefined-behaviour? The lifetime of a local should be as short as it reasonably can be.
My take on this:
pro:
- Storage concerns are separated and grouped at the top.
- Logic code is more compact, helping readability.
- Stack use can be determined at a glance.
- Looking up a variable's type is faster in cases where a variable is used throughout the code block. This is good to optimize, as you constantly need to look up variables when reading C code.
- Reflects that object lifetime of any stack storage object is the same regardless of where it is declared in the code block.
cons:
- For long functions, the distance between use an declaration lines can impair looking up a var's type. (having to scroll to get to the top of your function is a sign you need to break it up though)
- In many cases, a variable is only used in one location in the block and has a meaningful static initialization. Local declarations in this case readability, as it does not have to be looked up.
- "-Wuninitialized" exists, but passing pointer and defining 'default' value style can still cause read-before-write.
I tend to an in-between style, where code is grouped where it makes sense with group-local variables declared in front. Variables that are used throughout the entire code block body are declared at the very top.
Re: The Go Compiler Needs to Be Smarter
#40Does 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/link times creep up that level.