Following up on my recent project of bootstrapping Void Linux on ppc64le, I decided to quantify the exact performance penalty we pay when using generic distribution binaries on our Talos II workstations.
I compiled Firefox 152 natively using both GCC and Clang (with and without LTO/PGO) and ran a rigorous Speedometer 3.1 benchmark against the standard Firefox 151 package provided by Fedora 42.
To eliminate DVFS noise, the CPU was strictly pinned to 2.8 GHz, and tests were run in an isolated E27 environment using
--new-instance --private-window to avoid the unaccelerated paths of the standard safe mode.
The Build Times & Toolchain LimitsClang: 43m 30.668s
Clang + LTO: 45m 32.136s
Gcc: 67m 05.885s
Gcc + LTO: 84m 28.716s
Note on PGO: I attempted PGO builds, but the current toolchain state on ppc64le (specifically regarding VSX) makes it a dead end. GCC instrumentation resulted in an Internal Compiler Error, and Clang took over 3 hours (185m real time) only to produce a crashing binary.
Performance Results (Speedometer 3.1)FF151 / F42: 1.647; stdev = 0.018;
FF152 / GCC: 5.449; stdev = 0.086
FF152 / GCC+LTO: 5.518; stdev = 0.063;
FF152 / Clang: 5.478; stdev = 0.065;
FF152 / Clang+LTO: 5.779l stdev = 0.050.
Key Architectural Takeaways:- The VSX/JIT Effect: The native Clang+LTO build delivers a ~250% performance increase (a 3.5x multiplier) over the default Fedora 42 package. This heavily implies that standard distro builds are either running scalar code or heavily crippling the JS JIT compiler for stability.
- LLVM Dominance: Clang not only builds significantly faster than GCC, but it also scales much better with LTO.
- GCC UI Anomaly trimmed: During the tests, I noticed that regardless of LTO, the GCC-compiled binaries exhibit significant UI desynchronization (the "burger menu" lags about three cursor positions behind). The SpiderMonkey engine runs fine, but the interaction with system libraries (GTK/Cairo) is visibly degraded compared to the Clang build.
Has anyone else experienced similar UI latency with GCC-compiled GTK applications on POWER9, or is this strictly a Mozilla codebase quirk when compiled outside of LLVM?
The full raw data, generated charts, XBPS build templates, and the critical patch fixing VSX alignment issues in the Mozilla codebase are available in my public GitHub repository here:
https://github.com/DKnoto/Firefox-Benchmarks
Recent Posts