-
-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
LLVM Clang is 20% slower than it should be #77975
Comments
As an example for things that can be tweaked in the formula: Building with
Not sure why everything is slower than in my original benchmark, but what's important is the relative difference between each compiler. (Maybe my laptop was tired after building LLVM...) Another is perhaps to instead follow the suggestion here: https://llvm.org/docs/BuildingADistribution.html I think the |
Just to make the comparison a bit more direct, we can do the same exercise with
|
I built LLVM with PGO according to the guide in the upstream docs. It did improve on my original benchmark somewhat: Apple Clang is only 14% faster at building However, it did create substantial improvements with some other benchmarks. With PGO:
Without PGO:
With PGO:
Without PGO:
|
This patch implements various improvements I found while working on Homebrew#77975. A few are cosmetic, but the primary substantive change is the use of the `C_INCLUDE_DIRS` CMake variable. [1] This adds Homebrew's `include` directory along with Xcode's system header path to Clang's default include search path. The former change aligns our Clang with Apple's, which searches `/usr/local/include` by default. [2] The latter change allows the bottle to be poured in Xcode-only installs so that we no longer need the `pour_bottle?` check. We also add `/Library/Developer/CommandLineTools/usr/include` to the default header search path to align our build with Apple's. [1] https://reviews.llvm.org/D69221 [2] From `/usr/bin/clang -E -xc -v /dev/null`: Apple clang version 12.0.5 (clang-1205.0.22.9) [snip] #include "..." search starts here: #include <...> search starts here: /usr/local/include /Library/Developer/CommandLineTools/usr/lib/clang/12.0.5/include /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include /Library/Developer/CommandLineTools/usr/include /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory) End of search list. [snip]
This builds LLVM with profile-guided optimisations. I've adapted the build from upstream documentation. [1, 2] This does mean that builds will now take 2-3x longer than before. LLVM currently takes about four hours to build at most (including recursive dependents), so the additional time isn't as bad as some other formulae that require long CI runs. Moreover, the collective time this saves users of the LLVM formula should make the additional build time worth it. LTO is another potential optimisation that I haven't enabled here. This appears to be enabled in Apple's default build [3], but is a little complicated to implement for an LLVM distribution that includes static archives [4]. Closes Homebrew#77975 [1] https://llvm.org/docs/HowToBuildWithPGO.html#building-clang-with-pgo [2] https://github.com/llvm/llvm-project/blob/33ba8bd2/llvm/utils/collect_and_build_with_pgo.py [3] https://github.com/apple/llvm-project/blob/swift-5.4-RELEASE/clang/cmake/caches/Apple-stage2.cmake#L30 [4] https://llvm.org/docs/BuildingADistribution.html#options-for-optimizing-llvm
brew gist-logs <formula>
link ORbrew config
ANDbrew doctor
outputbrew update
and am still able to reproduce my issue.brew doctor
and that did not fix my problem.What were you trying to do (and why)?
Build formulae using LLVM Clang instead of system Clang. This is needed to resolve build failures on Mojave for certain formulae that use C++17 features that haven't been implemented in older versions of Clang.
See, for example: #77819, #77505, #77504, #74765
What happened (include all command output)?
The Mojave nodes systematically took a longer time to complete their runs than the other Intel nodes:
This pattern does not hold for #74765 (gRPC) because, at the time of that PR, there were several gRPC-dependent formulae (e.g.
mavsdk
,bear
) that declareddepends_on macos: :catalina
.What did you expect to happen?
The Mojave nodes are typically 20-30% faster than the other Intel CI nodes, so I expected Mojave CI to not be slower than the other Intel CI nodes on those PRs.
It's possible that this is just a regression coming from LLVM 12, but I think there are still tweaks we can do with the formula to try to minimise this gap.This is not a regression from LLVM 12. Doing the same exercise withllvm@11
shows an even larger performance gap. See succeeding comments in this issue.Step-by-step reproduction instructions (by running
brew
commands)The text was updated successfully, but these errors were encountered: