Earlier quoted context omitted.
Look up suckless. It has a specific meaning and history.
Indeed. suckless refers to https://suckless.org/philosophy/
Thanks. I had never heard of it.
The Go Compiler Needs to Be Smarter
21–30 of 119 posts
Re: The Go Compiler Needs to Be Smarter
#22Correct 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.
Re: The Go Compiler Needs to Be Smarter
#23The 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
Re: The Go Compiler Needs to Be Smarter
#24This is a very interesting at a time when we're seeing what we can replace C++ with. (yes, rusticles, I know rust exists)
I think go is mostly used to replace Python and Java & co.
Re: The Go Compiler Needs to Be Smarter
#25Sure, 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…
> 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.
The Ruby implementations don't really do that. They use "inline caches" so this lookup normally only happens once per call-site.
Re: The Go Compiler Needs to Be Smarter
#26A 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 goes to show that while a self hosted build system is nice, you forgo decades of gcc/llvm optimisations. https://github.com/golang/go/issues/17566
Re: The Go Compiler Needs to Be Smarter
#27Correct 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.
Realistically, compilation speed is something every major language is going to try to improve upon to improve adoption.
I haven't looked at the internals of the go compiler, but it seems a bit simplistic perhaps in the interest of improving speed. For example, it stops outputting errors after a point when it can clearly go further after having demonstrated that it's parser can recover. The error messages have lots of room for improvement, particularly compared to Rust.
Re: The Go Compiler Needs to Be Smarter
#28Go 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.
Re: The Go Compiler Needs to Be Smarter
#29Correct 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.
Realistically, compilation speed is something every major language is going to try to improve upon to improve adoption. I haven't looked at the internals of the go compiler, but it seems a bit simplistic perhaps in the interest of improving speed. For example, it stops outputting errors after a point when it can clearly go further after having demonstrated that it's parser can recover. The error messages have lots of…
I think one of the pain points that Go addresses is the compilation speed of large C++ projects at Google, and it's one of the reasons it was made in the first place. From what I know C++ and Rust are in the same ballpark in terms of compilation speed, while Go gives a noticeable improvement.
Re: The Go Compiler Needs to Be Smarter
#30Sure, 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/
> 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.