Profile guided optimizaton

[imbaczek]

Release builds could receive special treatment: build with -fprofile-generate, play around for a while, and then rebuild with -fprofile-use. Some sources state that PGO yields up to 10-15% performance gain, and that's quite a lot.

Just food for thought. A way to automate this (some lua startscript) would be cool.

BTW first post here

[Tobi]

I'd have to take a look at implementing that in the build system.

Also it takes quite some time since it kills possibility for fully automated builds.

Though if the profile files are platform independent and not too big, it may be relatively easy to do this.

Do you happen to know how prone the profile data is to code changes? That is, can I modify stuff after having profiled with the -fprofile-use build just ignoring the modified conditionals?

If it isn't too prone for errors so e.g. hotfixes can be made without needing two rebuilds and some playing of Spring to generate profile data, then it may very well be worth it.

[imbaczek]

I guess no source code change is possible, since it invalidates offsets.

See also:
http://gcc.gnu.org/onlinedocs/gcc-4.2.1 ... dprofiling
http://gcc.gnu.org/onlinedocs/gcc-4.2.1 ... ze-Options

[Tobi]

I even get coverage mismatches (in some luabind files) when compiling identical sources first with -fprofile-generate then with -fprofile-use.

I measured a small 1.1% (diff. demo) - 1.4% (same demo as used for profile generation) improvement in performance* in a quick test with a few hundred flashes/weasels and some krogs.

* performance defined as the total simulation time reported by the time profiler in Spring at the end of the demo (this seemed fairly reproducable, contrary to looking at FPS)

[imbaczek]

Try add some air combat to that, aircraft due to their speed update LOS frequently and I'd expect biggest improvement there. If it's not more than 5%, I guess we can abandon the idea for now.

Coverage mismatches could happen due to the way stuff is inlined with and without profile data... just a guess.

Also I wonder whether profile-optimized and normal build will stay in sync. This may be a problem for Linux players who build the game themselves or use a unofficial repository.

[Tobi]

Try add some air combat to that, aircraft due to their speed update LOS frequently and I'd expect biggest improvement there. If it's not more than 5%, I guess we can abandon the idea for now.

Yeah, the cost of generating the profile data, the manual intervention and the double compile is way to high to start using it if it doesn't give at least 5, or even 10% improvement.

If it proves useful, then I'd prefer to write small profiling / unit test programs that can be run automatically by the build system then to have to do a manual profile generation step for every release build. Of course these tests would need to accurately represent average usage of the particular classes.

As an alternative, if simulation code is factored out, a commandline simulation code profiler could be made pretty easily, which could be run automatically as part of a two stage build process with PDO.

Coverage mismatches could happen due to the way stuff is inlined with and without profile data... just a guess.

I find it pretty strange, all other compilation options where identical... but well, I could easily recompile the failing files without -fprofile-use and link them with the rest of the code.

Also I wonder whether profile-optimized and normal build will stay in sync. This may be a problem for Linux players who build the game themselves or use a unofficial repository.

I didn't notice any differences in my test demos. Would have to be tested a bit more though, but since optimization level doesn't matter either I would be surprised if PDO does matter.