Go 1.22 Inlining Overhaul
docs.google.com
Go 1.22 Inlining Overhaul
1–10 of 19 posts
Re: Go 1.22 Inlining Overhaul
#2All in all, looks like good ideas.
Re: Go 1.22 Inlining Overhaul
#3Anyone know what the "PGO" referred to in TFA is?
Re: Go 1.22 Inlining Overhaul
#4Anyone know what the "PGO" referred to in TFA is?
[deleted]
Re: Go 1.22 Inlining Overhaul
#5Anyone know what the "PGO" referred to in TFA is?
profile guided optimization https://learn.microsoft.com/en-us/cpp/build/profile-guided-o...
Re: Go 1.22 Inlining Overhaul
#6Re: Go 1.22 Inlining Overhaul
#7All in all, looks like good ideas.
It looks convincing enough honestly
Re: Go 1.22 Inlining Overhaul
#8I wonder if a "release" build flag makes sense for go. There is so much optimisation potential left on the table for the sake of build time.
The current build should be "Dev" and a new "release" should be introduced.
Re: Go 1.22 Inlining Overhaul
#9I don't know if you have ever written an inliner, but it seems simple enough until you realise you are trying to restrain a rabid dog on a leash.
I wrote one a long time ago that was a part of a project that was moderately popular, but it had issues and incremental changes had a tendency to trigger weird edge cases. in the end someone with a CS PhD wrote a different one (while keeping quiet on the awfulness of my implementation) and it was so much nicer in every way. Reading his code was like reading poetry.
That was when I realised code should be deliberate. Every line is a step towards a goal. I think that is why rewriting something when you understand the problem domain better can be so liberating.
Re: Go 1.22 Inlining Overhaul
#10I don't know if you have ever written an inliner, but it seems simple enough until you realise you are trying to restrain a rabid dog on a leash. I wrote one a long time ago that was a part of a project that was moderately popular, but it had issues and incremental changes had a tendency to trigger weird edge cases. in the end someone with a CS PhD wrote a different one (while keeping quiet on the awfulness of my imp…
A good example on C and C++ code, is the UB that isn't there in first place, but gets triggered due to the way code is inlined, and suddenly the optimizer becomes aware of optimization opportunities that wouldn't be taken, if it wasn't for the code being inlined.