3 ms·
A 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
by drej 6y ago
A 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 https://github.com/golang/go/issues/17566
- pjmlp 6y agoThose 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.
- entha_saava 6y ago> Also many other languages keep having backend issues, because those optimizations are too focused on C and C++ code semantics. Attribute it to LLVM monoculture.
- jcranmer 6y agoAttribute it to benchmarks people care about being written in C/C++ (with maybe a dash of Fortran). e.g., SPEC CPU.