There’s also https://github.com/golang/go/issues/19348; they’ve laid some groundwork to inline more, but they need to keep stack traces correct and compile-time cost reasonable.
I already expressed dislike for //go:noinline, and I will firmly object any
proposal for //go:mustinline or something like that, even if it’s limited
to runtime.
Can anyone elaborate on this? Is it just a matter of abuse? I not-so-infrequently find myself in a position where a function i want inlined doesn’t get inlined, and I’m thankful that i have the tools to force the issue. I’ve found the other direction useful as well, particularly for profiling.
Can anyone elaborate on this? Is it just a matter of abuse?
I can’t think of a way in which to abuse noinline, can of must, and feel I’d want an out if I know better than an analyzer. But even more, I’d like the tooling to introspect what, and why a function is or isn’t being inlined, without being force to read the intermediary code/assembly. But, honestly, there are probably only a handful of cases in a 100,000 lines of Go where I might even consider it worth attempting to inline to speed something up. In that case, better to trust the analyzer and hope that the heuristic doesn’t hurt more often than gain.
In my code at work, yeah, I almost never care about function inlining. But in my open source/spare time work, controlling function inlining is critical in some cases for performance. I guess it would be kind of cool to learn why inlining did or didn’t happen, but I’d still want to be able to override it.
One reason I can think of to object to a general mustinline directive is that it moves Go much closer to a situation where interpreting compiler directives in comments is mandatory for any implementation, even if they are not officially part of the language specification. If enough people write code that only runs correctly (including necessary minimum performance) when inlined, then all Go compiler implementations must support //go:mustinline in practice. If Go is going to do this it should really make such compiler instructions part of the official standard, which opens up a whole can of worms. Arguably build directives have already opened this can of worms, since I think a Go implementation can’t really build Go packages in practice without understanding them (‘have users write Makefiles to control what’s compiled’ is not really an answer).
(Restricting this to the runtime is less dangerous, since the runtime is tightly coupled to the compiler. But allowing its use in the standard library outside of runtime-coupled packages would be a problem, since other Go compilers may well want to use as much of the standard library as possible.)
For the same observation but accompanied by investigation instead of ranting, watch George Tankersley’s GopherCon 2017 lightning talk: https://www.youtube.com/watch?v=7y2LhWm04FU&list=PL2ntRZ1ySWBfhRZj3BDOrKdHzoafHsKHU&index=11
To be fair, the article on lemire.me did not seem like ranting. And I’m a plush-gopher-on-my-desk fan of Go :-)
https://github.com/golang/go/issues/17566
Some discussion of the issue here, didn’t make the cutoff for 1.9 but might make 1.10
There’s also https://github.com/golang/go/issues/19348; they’ve laid some groundwork to inline more, but they need to keep stack traces correct and compile-time cost reasonable.
This bit is interesting:
Can anyone elaborate on this? Is it just a matter of abuse? I not-so-infrequently find myself in a position where a function i want inlined doesn’t get inlined, and I’m thankful that i have the tools to force the issue. I’ve found the other direction useful as well, particularly for profiling.
I can’t think of a way in which to abuse
noinline, can ofmust, and feel I’d want an out if I know better than an analyzer. But even more, I’d like the tooling to introspect what, and why a function is or isn’t being inlined, without being force to read the intermediary code/assembly. But, honestly, there are probably only a handful of cases in a 100,000 lines of Go where I might even consider it worth attempting to inline to speed something up. In that case, better to trust the analyzer and hope that the heuristic doesn’t hurt more often than gain.In my code at work, yeah, I almost never care about function inlining. But in my open source/spare time work, controlling function inlining is critical in some cases for performance. I guess it would be kind of cool to learn why inlining did or didn’t happen, but I’d still want to be able to override it.
One reason I can think of to object to a general mustinline directive is that it moves Go much closer to a situation where interpreting compiler directives in comments is mandatory for any implementation, even if they are not officially part of the language specification. If enough people write code that only runs correctly (including necessary minimum performance) when inlined, then all Go compiler implementations must support //go:mustinline in practice. If Go is going to do this it should really make such compiler instructions part of the official standard, which opens up a whole can of worms. Arguably build directives have already opened this can of worms, since I think a Go implementation can’t really build Go packages in practice without understanding them (‘have users write Makefiles to control what’s compiled’ is not really an answer).
(Restricting this to the runtime is less dangerous, since the runtime is tightly coupled to the compiler. But allowing its use in the standard library outside of runtime-coupled packages would be a problem, since other Go compilers may well want to use as much of the standard library as possible.)