Optimization training data (PGO/IBC) in source-build

[dagood]

PGO/IBC optimization training data is used in CoreCLR and CoreFX (maybe more that I don't know about). There are two issues with using that in source-build:

1. The tooling to generate/use the data isn't buildable from source (not OSS).
2. Optimization data generation requires an existing product.
   • This forces the build to be (at least) two-staged: first to generate an unoptimized product so that we can generate the training data, then again to build the product using that training data.
   • This resembles the pre-built binary problem, but I don't think we need to seed the process with anything built beforehand.

Is it possible to fix (1)?

If we can't accomplish this, what impact does it have on source-build users?

Currently the optimization data packages are dummied out (for the offline build):

source-build/tools-local/init-build.proj

Lines 149 to 152 in a680f36

	<DummyPackage Include="optimization.PGO.CoreCLR" Version="2.0.0-release-20170711-0120" />
	<DummyPackage Include="optimization.linux-x64.PGO.CoreCLR" Version="2.0.0-release-20170711-0120" />
	<DummyPackage Include="optimization.windows_nt-x64.PGO.CoreCLR" Version="2.0.0-release-20170711-0120" />
	<DummyPackage Include="optimization.windows_nt-x86.PGO.CoreCLR" Version="2.0.0-release-20170711-0120" />

@dotnet/source-build-contrib

[dleeapho]

/cc @brianrob @adiaaida

[omajid]

Thanks for getting this conversation started.

Is it correct to say this is about optimization performed by the native compiler. Is there something on the managed side as well?

Do you have any idea of the performance impact of optimization training data? Is it 1% to 2% or significantly more?

This forces the build to be (at least) two-staged: first to generate an unoptimized product so that we can generate the training data, then again to build the product using that training data.

Is this data platform, architecture or compiler dependent? If not, could it be documented, run once and then added to the repository per release?

This forces the build to be (at least) two-staged: first to generate an unoptimized product so that we can generate the training data, then again to build the product using that training data.

That shouldn't be a problem as long as both builds are source-build based with the additional data file as a new input for the second build.

[dseefeld]

Adding to General Prebuilt Removal. We can't have this binary data as a prebuilt, but need to determine if or how to deliver this with source-build.

[dagood]

Spotted this comment about open sourcing dotnet-pgo, envisioned as a replacement for ibcmerge and ibc data sometime post-5.0. dotnet/runtime#34422 (comment). Text-based and/or reproducible training data seem like the next missing parts to get this into source-build.

[MichaelSimons]

FSharp has enabled PGO and would benefit from this as well - see dotnet/fsharp#17513