Repository navigation
build: PGO-enabled release builds #1409
Description
Activity
- addedbuildIssues and PRs related to Node.js builds or CI infrastructure.Issues and PRs related to Node.js builds or CI infrastructure.benchmarkIssues and PRs related to Node.js benchmarks and benchmarking infrastructure.Issues and PRs related to Node.js benchmarks and benchmarking infrastructure.
on Apr 13, 2015 I think the biggest problem here is your first point - we don't have a good set of reality-based benchmarks. I've been itching to try and get a WG spun up to focus on this but it hasn't clicked so far (btw I'm not a benchmark person, I'm just interested in seeing this happen). For now @iojs/build have been discussing some regular benchmarking system for builds but this would still require a better benchmark suite.
PGO's net effect may be zero.
Do you have any numbers to share on experiments, or even a gut-feel on this? I've not had experience with PGO compiles.
@rvagg another issue is that we (@iojs/build) don't really cater for build permutations - so we can't uphold quality assurance (or if it even works across our architecture). It's slightly off topic to this PR, so I'll stop here. I'd also like to see results of this since the PGO tests I've tried in other software hasn't really shown any strong benefits. It's hard to measure though (as mentioned above).
Do you have any numbers to share on experiments, or even a gut-feel on this? I've not had experience with PGO compiles.
It was a while ago and I didn't properly benchmark it. I ran an x64 PGO build through some http_simple_auto benchmarks and it was about 7-9% faster after but not consistently so. http_simple is notoriously fickle though.
The binary (after stripping) was a few 100 kB smaller though, so that may have helped. In retrospect, I should have profiled the before and after binaries with
perf recordand check where the differences are. Something for the next guy or gal. :-)By the way, I turned on -Wl,--gc-sections in the non-PGO build to remove dead code. It's currently disabled because of buggy toolchains but I think we should be able to safely turn it on again. IIRC, the issue was with gcc 4.4 and/or 4.5 in combination with particular binutils versions.
Maybe you can pull some benchmarks from projects like
expressorws, or other popular(npm top 5/10/20?) modules to get more "real" examples/cc @nodejs/benchmarking - perhaps you can incorporate this into your roadmap? I'll close this issue.
to get more "real" examples
Running profiling against such cases should also be preferred over internal benchmarks since they are more closer to 'real-life usage'. Actually Firefox has some very complicated PGO cases to mimic daily use cases.
(What's the status of this issue now?)
(What's the status of this issue now?)
I don't believe anyone is or has been working on it.
- added a commit that references this issue
on Aug 31, 2018 - added a commit that references this issue
on Sep 4, 2018 - added a commit that references this issue
on Sep 27, 2018 - added a commit that references this issue
on Oct 3, 2018
This is something that has been at the bottom of my TODO list for some time now. I don't seem to get around to it so I thought I'd file this issue in the hope that someone else might. :-)
I'd like to investigate doing release builds with profile-guided optimizations enabled. Strawman Makefile change:
The idea is to build an instrumented binary first, run the benchmarks to collect profile data that tell the compiler where and what to optimize, then build the final binary using the data from the previous step.
Open questions / unresolved issues: