cmd/compile: profile-guided optimization #55022
Comments
|
Change https://go.dev/cl/430355 mentions this issue: |
We propose adding support for profile-guided optimization (PGO) to Go. For golang/go#55022. Change-Id: I9bf8afc4858a530bc32fc2b40698209a45695203 Reviewed-on: https://go-review.googlesource.com/c/proposal/+/430355 Reviewed-by: Michael Pratt <mpratt@google.com>
prattmic
added
the
compiler/runtime
|
This looks very interesting! Starting with the pprof format sounds good, but I have some concerns about its verbosity in two ways. First, the files can be really big and processing them can be slow. When I work with profiling data manually, I often start with pprof-format files that include hundreds or thousands of samples, usually covering less than one thread-minute. For PGO, I'd be inclined to use "the most and best data available". For some applications I support, that means multi-megabyte pprof-format files which take multiple seconds to load. That's a big file to add to an application's source control repository (for build environments that work that way), and a big build speed hit if it applies to every package. The approach of "Some of these downsides can be solved transparently by converting the profile to a simpler, indexed format at build time and storing this processed profile in the build cache" sounds promising, but I wonder if that format should be obtainable through some explicit Second, how can application owners understand what the compiler is learning from the profile? When I encounter a bug that might be affected by or otherwise involve PGO, I'd like to be able to report it (including steps to reproduce) without accidentally disclosing proprietary information about the rest of my applications' performance and without accidentally changing the compiler's PGO-related decisions. When I have the choice between using a 100kB pprof file or a 10MB pprof file, I'd like to know if using the more detailed file actually changes the results. When reviewing a change to the PGO input file (maybe to adjust its weight towards more latency-critical parts of the app), I'd like to know what it's communicating to the compiler. These could also be addressed by a "simpler, indexed format" that is semi-stable and human-readable / human-redactable. |
|
@rhysh thanks for the feedback! Yes, if we later switch to a different format, we will provide a tool to convert profiles between the formats. And yes, if we choose a different format we will consider how to make it more human-readable. (We considered this possibility but it was unclear to me how to do that. There is also a range of possibilities. The human readable form could be very low level, basically a textual representation of the raw profile, to very high level, basically a list of "compiler optimization directives", or something in between.) Related, I think the compiler will have an option to output what optimizations are done based on the profile, either through the |
|
Visibility into the compiler's decisions via If so, it sounds like we have the "simpler [...] format" described in the proposal, in an ad-hoc way. Maybe ad-hoc is all we need, and would keep the messier and less stable parts of the ecosystem out of the main This sounds like the "basically a list of 'compiler optimization directives'" option. What design challenges did you encounter with that? Thanks @cherrymui ! |
|
Like @rhysh, I feel strongly that the
|
|
Interesting idea about compiler optimization directive list for bug report. Thanks. I thought for bug report due to PGO we would expect one to share the profile in order to reproduce the buggy build. It is understandable that this can be difficult in some cases. Maybe we can consider supporting an optimization list, even just for debugging purposes. (FWIW, we even had a prototype for optimization list (thanks @dr2chase) which I used for early experiments.) One challenge is how to generate such an optimization directive list from raw profiles. For a streamlined user experience, one would take profiles from production binary, and Another benefit for profiles is that we can do multiple optimizations based on, say, a CPU profile. If we add a new type of PGO-based optimization, one would automatically get the optimization without taking a new profile. For optimization lists, one would need to explicitly add it to the file. I'm not really clear what the optimization list would include. Should it be binary (boolean) options, or weights? Binary options sound simpler, but maybe weights are better for optimizations, so the compiler can take into account the information from source code and its own analysis? There is also the question about the file becoming stale. Of course profiles can also become stale. It might be possible to design an optimization directive list format that is resilient to staleness. Maybe one option is to have the compiler
|
|
Do you have any concrete examples of how an optimization file gets generated for a specific profile? Any existing compilers do this today? Please let us know.
Typically compiler optimizations such as inlining, specialization, code layout, register allocation and instruction scheduling can use profile information to improve application performance by optimizing hot-paths.
|
|
Non-main packages As a package writer, I cannot supply any improvements. It would require package users to implement pgo benchmarks that hits my package. Writing these benchmarks to build cpu profiles are far from trivial. As a result 99% of all compiles with my packages would be without (useful) pgo. You mention this as future work, but it seems like a big miss. Platforms This will only cover platform independent code. Much optimized code has separate code paths for different platforms. As proposed I don't see any reasonable way to handle multiple platforms automatically, for example when cross-compiling. You could make this a user problem, and say they should use Future Optimization Scope I may be lacking imagination, but I don't see the scope of this going much beyond inline decisions. Maybe with branch-information, you could re-order unordered To justify such a rather complex setup it is important to keep the end-goal in sight. Counter Proposal: Simplify Proposal I appreciate the intent to make this automatic and low-effort. But writing the benchmarks and/or capture useful profiles is a big task and for a big application with many subsystems it will be a massive. While it proposes to just run pprof on a production server, apply the profile -> faster application, it isn't really that simple, since profiles would need to continuously be captured as code changes. I very much agree with Josh, et al, that this should be simpler and in the hands of the developer. To add to that, I know that Go doesn't like pragmas, but it seems to me with a few, well designed pragmas we could get the same result, that doesn't have all the problems. As far as I can see having a program propose pragmas (or code reordering) from a profile would be just as simple, and allows you to review the proposed changes before they are committed. If Go still isn't ready for performance related pragmas, then an external file describing the same would also be an (IMO suboptimal) solution. I dread a bit how you would specify inlining at callers and auto-vectorization of a |
|
@klauspost Given inlining is the most significant optimisation mechanism, I believe even at the current status, pgo is a much valuable improvement. In addition to inlining, pgo can be applied to interface dispatch, which helps devirtualise method invocations, profiling on branch-taken frequency helps produce better code layout at the very least, and guides the optimiser toward better decisions in other operations such as loop unrolling, cloning operations through phi nodes, in extreme cases branch pruning is also a possibility. While pragmas or external decorative files work on call graphs, optimisation decisions are most optimal when having information in the call trees, this would be a suboptimal proposal. Additionally, it is not internal details, so I would disagree with this idea. |
|
@merykitty Thanks! I see your point with interface dispatch, where knowing common implementation could output implementation specific branches. The other cases I don't really see as something that couldn't be done with pragsmas. Granted, generic implementations could make this hard to control, since they would probably apply to all instances. I don't see how you can make branch pruning without the compiler being able to prove that branches are impossible, in which case you don't really need pgo. Branch reordering and loop unrolling (without vectorization) has very limited impact on modern CPUs. Either way, I stand by my point, that as proposed seems like a complex system that is hard to use correctly, and will provide limited benefits. It is not a "set up and forget", which is my main problem. I am hoping for a simpler system that is more controllable, that doesn't require 'main-function' implementation with continuous updates required, which provides 90% of the benefits. |
|
One worry I have with using profiles directly is that it can easily be an unstable mechanism. If I profile a program's current build and use that profile to rebuild it with PGO, grabbing another profile would likely result in fairly different results. For example, if a function call used to take ~2% of CPU time due to being in a very hot path and PGO now inlines it, then it could become far less relevant in the second profile. I imagine we want developers to only use PGO with profiles obtained from runs without PGO. Can we restrict that to prevent confusion? |
|
@mvdan The ability to collect profiles from a PGO-optimized binary is actually a core requirement in our design because it simplifies profile collection significantly (you can collect directly from production deployments without need for some kind of unoptimized "canary" deployment used only for profile collection). It certainly has the challenge you mention, which we call "iterative stability" and discuss here and here. Sections 4.2.1 and 5.2 of the AutoFDO paper also discuss this. This is something we will need to pay close attention to and test well to make sure results are stable, and may be an area where additional metadata could help (e.g., collecting a CPU "last branch record" (LBR) profile would tell us which basic blocks are frequently executed, even if they have become much cheaper, so, used carefully, that could further mitigate this issue). |
|
@josharian Having a list of optimization directives (or pragmas in the source) is something we've thought about, and definitely has pros and cons. I certainly think we want PGO to be applicable from a profile (which I think you agree with?), but whether translation to optimization decisions happens directly in the compiler, or as a pre-processing step. Some thoughts on list of advantages below. Note, this list actually talks about two axes: profile vs optimization list and binary vs plain text format. I think we could decide along either of these axes (e.g., we could use a plain-text format that describes the pprof profile).
I'm not sure I fully agree with this. While I agree that the compiler will be simpler if it only takes a list of directives rather than having to process a profile, something still needs to convert the profile to a list of directives. That new tool will contain the complexity, and share a lot of similarities with the compiler, perhaps even directly sharing code, depending on the specifics of the directives. e.g., if inlining directives are binary decisions ("inline this function"), then the conversion tool should probably contain a near copy of the compiler's inlining heuristics so that it makes very similar decisions. That is perhaps less important if the directives are more abstract (providing an inlining importance "weight"?), but if we go too abstract then we are probably just describing a profile anyways. As Cherry mentioned, one option here is that the compiler could accept either a profile or optimization list. When given a profile, it generates the optimization list to be used for future compilations.
I agree this would be easier to test/debug because it adds an intermediate format which you could test both sides of.
100% agreed that a plain test format and an optimization list are more transparent about what is happening in the build.
While I agree that an optimization list makes manual optimization tuning easier/possible, that has not been a goal of this proposal, and it is something we have avoided adding pragmas for (also likely a reason we wouldn't have PGO work by adding pragmas to source code). I think it is a bigger discussion if we want to support custom tuning of optimizations.
This strikes me as out of place in your list. We absolutely want to support (and encourage!) merging profiles from multiple instances in order to get a more representative sample. This seems to be a point in favor of pprof, as it is easy to merge pprof profiles ( On the other hand, optimization lists seem difficult to merge. If one list says "inline foo" and the other says "do not inline foo", how do you merged? It seems in this case you'd still want to merge the profiles prior to generating the optimization list.
Earlier in our design we were planning to create a new PGO format specifically to have the flexibility of adding information beyond CPU profiles. We switched to proposing pprof directly because the format, while not perfect, is actually quite flexible. e.g., dynamic type info could be encoded as a Label on Samples of calls describing the type being called (though for calls the type is already obvious from the call destination, so not the best example). Stack sizes could be sampled as Samples with Location == gp.startpc, and value == stack size. The format is not perfect and we may find ourselves limited in the future (discussion here), but I think there is a lot of runway.
Agreed that a plain-text format makes fix-ups easier. We've discussed tooling for renames for pprof files, but plain text is easier.
I'm not sure what you mean by this, could you expand? |
|
@klauspost My opinion is that history tells us that using pragmas to guide optimizations doesn't sustain over time. What happens is that someone does a bunch of analysis with a specific compiler version and a specific set of benchmarks, and writes a bunch of pragmas that makes those benchmarks faster. So far so good. But two years later the compiler has changed, the libraries have changed, and the program has changed. The existing optimization pragmas have not changed, and no longer do any good, and occasionally actually do harm. Profiling can have the same problem, of course, if nobody updates the profiles. But updating the profiles is a much simpler task than analyzing performance in detail, and therefore tends to happen more frequently. In the best case, updating the profiling is simply automated. So over the long term, I believe that profile guided optimization is a better approach for most projects. It's unlikely to beat careful analysis and hand tuning at the point in time when that happens. But profile guided optimization is much cheaper in what is for most projects the greatest expense: developer time. Just my opinion, of course, but based on experience. |
|
@klauspost, just a small point
Branch pruning here means splitting everything below the if to separate hot paths and cold paths in the whole function. |
This is something we've been thinking about recently and are open to suggestions. I think we may want automatic build configuration selection eventually, but the details are tricky. Do we use suffixes, like .go files ( What we've proposed I think is the MVP option which remains forward compatible with future auto-selection we might do. (FWIW, I think that a single profile for all platforms is likely good enough for more users. A platform-specific one will of course be at least a bit better, but my intuition says that the vast majority of most profiles will be common across platforms. We could verify this with data by comparing profiles).) |
To add to what others have said, we've actually been keeping an eye toward many possible PGO-based optimizations while designing this. Here's a non-exhaustive list: Edit 2023-09-05: A more up-to-date and exhaustive list is here
|
|
@klauspost thanks for the feedback!
I totally agree that PGO for non-main packages are important (we want to do it for the standard library as well), and we spent quite some time considering it. But many details are still unclear to us. At the moment we're proposing what we know how to do, and leave the door open for future improvements including PGO for non-main packages. I think this is better than waiting.
This is not what we expected. Instead, we expect the user to take profiles from their main program. If in that program your package is in the hot path, PGO will apply to your package.
As @prattmic mentioned, we are proposing an MVP option which remains forward compatible with future improvements. As mentioned in the design doc
By "portable", for example, if the workloads are similar across platforms, the hot functions on one platform is likely also hot on another platform. See also "Input welcome" from the original post. We're particularly welcome input for naming default profiles.
I'm not really sure what your comment meant. But here is a (non-exhaustive) list of optimizations we plan to do in the future https://go.googlesource.com/proposal/+/master/design/55022-pgo.md#optimizations |
|
I will first admit that I do not have direct experience with profile-guided optimization in any other language, and so my line of questioning here may be naive. If this seems like a nonsense question, I'm happy to accept that as an answer to avoid anyone feeling the need to do my homework for me! 😄 The proposal and some of the commentary above discusses the fact that a particular set of profile information is specific to a particular version of the compiler (because it may generate code with different execution characteristics) and to particular input source code (because changing the program will at least change the behavior of the part of the program that changed, and may also have knock-on effects elsewhere from optimizations that are able to consider global information). I quite enjoy the fact that Of course I understand that profile-guided optimization cannot possibly be implemented with an automatically-maintained cache, because gathering profile information is always an explicit step and similarly it's up to the person running However, I do wonder if it seems feasible for the toolchain to automatically announce when a particular profile information file has been invalidated, so that I could be prompted to regenerate it. I assume "invalidated" is not a boolean value in this case but perhaps more like a code coverage report: how much of the program is still the same now as it was when this profile information was generated? What specific parts of the program are not covered by this profile because they have changed since the profile was generated? Was the profile generated from a program compiled with the same toolchain version as I'm currently using? (Hopefully this could also somehow take into account the degree to which the system can "make do" with mismatching profiles, giving higher precedence to changes that are outside the set that the compiler and trace format can account for automatically, as described in Stability to source code and compiler changes.) With what I've understood from reviewing the proposal so far it seems like it would be too expensive to track this sort of "profile coverage" on a per-line or per-statement basis, since it would seem to require retaining some sort of checksum for every single line/statement. But I wonder if it would be feasible to track at a coarser grain, such as per-function, per-file, or per-package, just to give the user something meaningful to understand the results against, so that they can then use their intuition to estimate whether the indicated objects have changed enough to warrant the effort of capturing fresh profile data. (For this question I'm imagining a situation where a team collects profile information semi-manually once and uses it for some time before semi-manually generating it again. I expect that the capability I'm describing would be far less useful in situations where a team is able to constantly gather profile information for a currently-running and feed it into the next build, as described in Iterative Stability. The software I spend most of my time working on is "shrinkwrap" software which we package and ship to users to run on their own computers, and so our ability to capture traces from real user runs is limited. "This feature is primarily intended for servers you can profile constantly" would be a perfectly reasonable argument to dismiss my questioning above, of course.) |
Yes, that was rather vague. :) It's similar to @apparentlymart's point (which is a good one). In many systems, performance properties are correctness properties. Losing key optimizations can cause performance regressions, which can cause existing provisioning to be insufficient, which can take down a system. Even merely slowing down a system can cause cascading failures. (I speak from experience, unfortunately.) The more opaque the toolchain and its inputs are, the harder it is to (a) write safety checks that detect performance problems before they make it to production and (b) diagnose performance issues after they make it to production. This is in some ways even worse with less severe regressions, which don't result in an obvious, immediate problem. The obvious approach here using pprof files is to have excellent compiler diagnostic output. This puts us in the same boat as (for example) current inlining tests: exec a build from inside a test and check for magic output strings. It's kind of a miserable existence, but it works. @apparentlymart's notion of a PGO fitness/staleness score would also help, albeit in a less fine-grained way. |
|
Or to put it a different way: How do I code review a commit that replaces one pprof profile with a new one? |
|
Thanks for the clarification, that makes sense. Having an optimization list doesn't solve the problem of determining if a new profile has "good" results, but it is at least easier to look at a diff and notice potentially worrying changes. (Though if the list is thousands of lines long and changes a lot from profile-to-profile, then I imagine that could also be difficult to review). |
|
Thanks. I think we all agree that we want the compiler to emit an optimization list for optimizations it does based on a given profile. Interesting idea about profile invalidation. I think that is a good point. And we can make the compiler emit some information when some profile information doesn't apply, either in the same optimization list file our some other file. I think it shouldn't be too hard or expensive. |
|
Change https://go.dev/cl/463684 mentions this issue: |
|
A preview of PGO support will be available in Go 1.20 (to be released very soon). 🎉 The user guide is available here. We have a few more problems to tackle before we're ready to call PGO generally available, which we're planning to work on for 1.21:
Then the next priority is tackling the long list of further PGO-based optimizations. |
|
Change https://go.dev/cl/464477 mentions this issue: |
For golang/go#55022. Change-Id: Ib2420c000dd0d6e7e272e217473e4ec192d4c730 Reviewed-on: https://go-review.googlesource.com/c/website/+/464477 Run-TryBot: Michael Pratt <mpratt@google.com> Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
|
Change https://go.dev/cl/474236 mentions this issue: |
Updates #58099. Updates #55022. Change-Id: I32eacdf9f008d16566e0b30230ecc25d110a9811 Reviewed-on: https://go-review.googlesource.com/c/go/+/474236 Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
|
I've filed a new umbrella issue to track PGO optimization opportunities: #62463 |
|
I read the discussion of some optimizations that need the basic block counters (unrolling, pgo register allocation, basic block ordering), but currently I do not see any issues or PRs or discussion of this feature. Is there any proposal or plans for implementing it? |
|
It's in the list of PGO optimization opportunities we'd like to pursue, but we don't yet have specific plans. We likely need discriminators in profiles (#59612) before we can do basic block-level PGO optimizations. |
With -pgo, for each configuration sweet automatically runs an initial profiling configuration. The merged profiles from these runs are used as the PGO input to a ".pgo" variant of the configuration. Comparing the base configuration to the ".pgo" variant indicates the effect of PGO. At a lower level, the config format adds a "pgofiles" map, which can be used to specify PGO profiles to use for each benchmark. Ultimately this sets GOFLAGS=-pgo=/path in BuildEnv. Some benchmarks may not currently properly plumb this into their build (e.g., the GoBuild benchmarks don't build the compiler at all). Existing benchmarks need to be double-checked that they actually get PGO enabled. For golang/go#55022. Change-Id: I81c0cb085ef3b5196a05d2565dd0e2f83057b9fa
go-build is a subtly strange benchmark. For every other benchmark, sweet builds the benchmarked program in set up, using Config.BuildEnv. go-build does not do that because the benchmarked programs (cmd/compile, cmd/link, and (to a lesser degree) cmd/go) are conveniently prebuilt in GOROOT. But this breaks the intuition that BuildEnv can control build flags for the benchmarked program, particularly for sweet run -pgo, where sweet itself expects a PGO flag in BuildEnv to impact the benchmarked program. Adjust go-build to follow these standards by copying GOROOT for each config and running `go install cmd/compile cmd/link` in the copied GOROOT, allowing BuildEnv to take effect. This fixes the general case for PGO, though it could use more work as really cmd/compile and cmd/link should receive _different_ PGO profiles. For golang/go#55022. Change-Id: I36e4486c79ee4200c2e10ccba913d559187bdad2
The current version of tile38 hard-codes GOFLAGS in its Makefile, which makes experimentation with compiler flags difficult. Upgrade to the latest version, which no longer overrides GOFLAGS. This will probably cause a slight discontinuity in performance results. For golang/go#55022. Change-Id: I1e42bd76d2bfcb7b9816447b260988f37bf32c87
With -pgo, for each configuration sweet automatically runs an initial profiling configuration. The merged profiles from these runs are used as the PGO input to a ".pgo" variant of the configuration. Comparing the base configuration to the ".pgo" variant indicates the effect of PGO. At a lower level, the config format adds a "pgofiles" map, which can be used to specify PGO profiles to use for each benchmark. Ultimately this sets GOFLAGS=-pgo=/path in BuildEnv. Some benchmarks may not currently properly plumb this into their build (e.g., the GoBuild benchmarks don't build the compiler at all). Existing benchmarks need to be double-checked that they actually get PGO enabled. For golang/go#55022. Change-Id: I81c0cb085ef3b5196a05d2565dd0e2f83057b9fa
With -pgo, for each configuration sweet automatically runs an initial profiling configuration. The merged profiles from these runs are used as the PGO input to a ".pgo" variant of the configuration. Comparing the base configuration to the ".pgo" variant indicates the effect of PGO. At a lower level, the config format adds a "pgofiles" map, which can be used to specify PGO profiles to use for each benchmark. Ultimately this sets GOFLAGS=-pgo=/path in BuildEnv. Some benchmarks may not currently properly plumb this into their build (e.g., the GoBuild benchmarks don't build the compiler at all). Existing benchmarks need to be double-checked that they actually get PGO enabled. For golang/go#55022. Change-Id: I81c0cb085ef3b5196a05d2565dd0e2f83057b9fa
go-build is a subtly strange benchmark. For every other benchmark, sweet builds the benchmarked program in set up, using Config.BuildEnv. go-build does not do that because the benchmarked programs (cmd/compile, cmd/link, and (to a lesser degree) cmd/go) are conveniently prebuilt in GOROOT. But this breaks the intuition that BuildEnv can control build flags for the benchmarked program, particularly for sweet run -pgo, where sweet itself expects a PGO flag in BuildEnv to impact the benchmarked program. Adjust go-build to follow these standards by copying GOROOT for each config and running `go install cmd/compile cmd/link` in the copied GOROOT, allowing BuildEnv to take effect. This fixes the general case for PGO, though it could use more work as really cmd/compile and cmd/link should receive _different_ PGO profiles. We also run the dummy build with the ExecEnv (matching how the actual benchmark will run) to avoid passing -pgo to those builds. For golang/go#55022. Change-Id: I36e4486c79ee4200c2e10ccba913d559187bdad2
go-build is a subtly strange benchmark. For every other benchmark, sweet builds the benchmarked program in set up, using Config.BuildEnv. go-build does not do that because the benchmarked programs (cmd/compile, cmd/link, and (to a lesser degree) cmd/go) are conveniently prebuilt in GOROOT. But this breaks the intuition that BuildEnv can control build flags for the benchmarked program, particularly for sweet run -pgo, where sweet itself expects a PGO flag in BuildEnv to impact the benchmarked program. Adjust go-build to follow these standards by copying GOROOT for each config and running `go install cmd/compile cmd/link` in the copied GOROOT, allowing BuildEnv to take effect. This fixes the general case for PGO, though it could use more work as really cmd/compile and cmd/link should receive _different_ PGO profiles. For golang/go#55022. Change-Id: I36e4486c79ee4200c2e10ccba913d559187bdad2
With -pgo, for each configuration sweet automatically runs an initial profiling configuration. The merged profiles from these runs are used as the PGO input to a ".pgo" variant of the configuration. Comparing the base configuration to the ".pgo" variant indicates the effect of PGO. At a lower level, the config format adds a "pgofiles" map, which can be used to specify PGO profiles to use for each benchmark. Ultimately this sets GOFLAGS=-pgo=/path in BuildEnv. Some benchmarks may not currently properly plumb this into their build (e.g., the GoBuild benchmarks don't build the compiler at all). Existing benchmarks need to be double-checked that they actually get PGO enabled. For golang/go#55022. Change-Id: I81c0cb085ef3b5196a05d2565dd0e2f83057b9fa
go-build is a subtly strange benchmark. For every other benchmark, sweet builds the benchmarked program in set up, using Config.BuildEnv. go-build does not do that because the benchmarked programs (cmd/compile, cmd/link, and (to a lesser degree) cmd/go) are conveniently prebuilt in GOROOT. But this breaks the intuition that BuildEnv can control build flags for the benchmarked program, particularly for sweet run -pgo, where sweet itself expects a PGO flag in BuildEnv to impact the benchmarked program. Adjust go-build to follow these standards by copying GOROOT for each config and running `go install cmd/compile cmd/link` in the copied GOROOT, allowing BuildEnv to take effect. This fixes the general case for PGO, though it could use more work as really cmd/compile and cmd/link should receive _different_ PGO profiles. For golang/go#55022. Change-Id: I36e4486c79ee4200c2e10ccba913d559187bdad2
go-build is a subtly strange benchmark. For every other benchmark, sweet builds the benchmarked program in set up, using Config.BuildEnv. go-build does not do that because the benchmarked programs (cmd/compile, cmd/link, and (to a lesser degree) cmd/go) are conveniently prebuilt in GOROOT. But this breaks the intuition that BuildEnv can control build flags for the benchmarked program, particularly for sweet run -pgo, where sweet itself expects a PGO flag in BuildEnv to impact the benchmarked program. Adjust go-build to follow these standards by copying GOROOT for each config and running `go install cmd/compile cmd/link` in the copied GOROOT, allowing BuildEnv to take effect. This fixes the general case for PGO, though it could use more work as really cmd/compile and cmd/link should receive _different_ PGO profiles. For golang/go#55022. Change-Id: I36e4486c79ee4200c2e10ccba913d559187bdad2
With -pgo, for each configuration sweet automatically runs an initial profiling configuration. The merged profiles from these runs are used as the PGO input to a ".pgo" variant of the configuration. Comparing the base configuration to the ".pgo" variant indicates the effect of PGO. At a lower level, the config format adds a "pgofiles" map, which can be used to specify PGO profiles to use for each benchmark. For golang/go#55022. Change-Id: I81c0cb085ef3b5196a05d2565dd0e2f83057b9fa
For golang/go#55022. Change-Id: I3755d2178f8672ef9c14a97256b1cd86a4883ea8
Note that L145 hard-codes the local GOROOT to test with. For golang/go#55022. Change-Id: I3755d2178f8672ef9c14a97256b1cd86a4883ea8
We propose adding support for profile-guided optimization (PGO) to the Go gc toolchain. PGO will enable the toolchain to perform application- and workload-specific optimizations based on run-time information. Unlike many compiler optimizations, PGO requires user involvement to collect profiles and feed them back into the build process. Hence, we propose a design that centers user experience and ease of deployment and fits naturally into the broader Go build ecosystem.
Detailed design can be found here.
In summary, we propose
gocommand will search for a profile nameddefault.pgoin the source directory of the main package and, if present, will supply it to the compiler for all packages in the transitive dependencies of the main package. We will also add a-pgo=<path>command line flag togo buildthat specifies a profile location to use for a PGO build, specifically,-pgo=<path>will select the profile atpath,-pgo=autowill select the profile stored in the source directory of the main package (the behavior mentioned above)-pgo=offwill turn off PGO entirelyoff. In a future release we plan to make it default toauto.BuildInfo.gocommand, and modify its optimization heuristics to use this profile information. Initially we plan to add PGO-based inlining. More optimizations may be added in the future.runtime/pprofornet/http/pprofpackages.Input welcome. Beyond input on the general approach, we're particularly looking for input on whether PGO should be default enabled in 1.20, and flag and file naming conventions.
If accepted, we plan to implement a preview of PGO in Go 1.20.
Raj Barik and Jin Lin plan to contribute their work on the compiler implementation (initial prototype in CL 429863, but not yet following proposed API).
See also previous discussions at #28262. Filing a new issue to make it clearer what we are proposing.
Thanks.
cc @aclements @prattmic @rajbarik
The text was updated successfully, but these errors were encountered: