Profile Guided Optimization

[Kronos3]

Rust has nice integration with LLVM PGO https://doc.rust-lang.org/rustc/profile-guided-optimization.html. We should take advantage and ship default PGO bins.

[kokroo]

@Kronos3 Do we have any sample load that we can test this with? Or do we want end users to provide their own sample loads to optimize their hot paths against?

We can't really ship something optimized by the PGO tooling, as that would be specific to a sample load. Unless that sample load is representative of most loads out there, end users would be better off running PGO with a script that I am writing right now, against their loads.

[Kronos3]

I'd assume many common Wasm binaries would produce similar profiles since they are spinning the same interpreter loop. I'd try looking at multiple common benchmarks and seeing how cross-feeding PGO bins affects their performance. Also providing a path for generating these profiles is the most valuable

[kokroo]

@Kronos3 PGO "guided" with the CoreMark bench is netting only a 0.26% gain :P

There are some Rust caveats that PGO can't optimise. I am trying to edit a few things in the source code to see if PGO or the compiler itself can optimise them. I want to keep the PR for this small and clean but it looks like it will get messy because of the changes required in the source to let PGO do its job.

[h313]

Enabling PGO in the spacewasm binary only rather than the full project that embeds spacewasm wouldn't be very useful, and might even lower performance. Given that we'd ideally have spacewasm be integrated into F-Prime, I'd imagine any mission will ideally have integration tests for the F-Prime tests, which will be used to guide PGO for the final binary. For optimal results, the final binary would also need to be compiled with link-time optimization enabled.

I think an ideal approach for us would be having a CMake build target with options to create profiling and optimization binaries that could hook into F-Prime or any other project. rustc seems to have an option to defer LTO until the link step. On our end, we'd need to enable ThinLTO which should provide us with some solid speedups as well.

[kokroo]

@h313 You're right and that's what I was trying to get at, just phrased badly I guess :D

The representative load you're describing (F-Prime integration tests driving PGO on the final, LTO'd binary) is the real world target. We just don't have that workload available yet I guess, so for now all I can profile against is spacewasm itself plus a few benches.

Where I still think this is worth pursuing: even when the shipped PGO'd spacewasm runtime isn't the deliverable, the profile is valuable as a discovery tool. It surfaces hot paths that can be optimized permanently in source, like restructuring the dispatch loop, branch ordering, etc. in a way that helps all loads. Some of that involves diving into Rust codegen caveats where PGO alone can't do much, but modifying the source lets both PGO and the compiler's optimization go further. That's the "ugly" part of the PR that I dislike, yet it may still end up like that.

On the build side, I fully agree that the right shape is a build target that lets the embedding project (F-Prime or whatever) generate the profile and drive PGO, with ThinLTO + deferred LTO at the link step. Happy to steer the tooling towards that if it checks out.

[Kronos3]

Implemented in #91