-
-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
build error: listnode.gcda missing-profile #74
Comments
This error is primarily caused by a difference in what code paths we actually exercise in the profiling stage. There are various tests that we have disabled because they're either flaky, or else do unsafe things to the host system (like changing the time), and we don't normally build with PGO, instead preferring the sampled approach taken by clang's AutoFDO since it's easier to manage at scale. I have a change up internally to suppress this error, but even after being suppressed, the resulting PGO data still won't be ideal since that currently gets done with the JIT disabled, and with the current method of collecting PGO by running tests, simply enabling the JIT during it won't do much, as it will primarily be profiling the actual JIT compilation rather than profiling the JIT'd code. Until that lands, to get things building, you can change this line: https://github.com/facebookincubator/cinder/blob/cinder/3.8/configure#L6784
With the caveat that this only fixes GCC on linux, as the clang pgo paths were removed at some point, so the change I mentioned above has to re-add them. Local testing (with a caveat these numbers were collected in a Ubuntu 22.04 image under WSL2 with clang and a couple other fixes applied due to the newer compilers) puts cinder in interpreter mode at ~5% faster on average than stock python 3.8 built and run in the same way (measured with the tooling mentioned in #72), though that's with both wins on some benchmarks and regressions in others. Some adjustments appear to be needed in order to get the benchmarks to run in a JIT-compatible way, as getting them to use JIT in the first place appears to need a bit of work, and even then they appeared to be using a separate process for every run, which would result in discarding the JIT'd code every single run. |
@Orvid is there more to be done here? |
5c04dc5 should have fixed this particular issue. |
seen on stock ubuntu:20.04 docker image with
--enable-optimizations
and NOT--enabled-shared
build is fine with
--enabled-shared
The text was updated successfully, but these errors were encountered: