3 ms·
And even worse, it's generating worse and ridiculously bigger code. So they spend a lot of effort for worse result. And apparently they don't catch serious pro
by nn3 8y ago
And even worse, it's generating worse and ridiculously bigger code. So they spend a lot of effort for worse result.
And apparently they don't catch serious problems in their build system on their own (profile feedback pass timing out and truncating data)
Overall not a great result at all for Mozilla. Where is the regression testing for performance? They are not data driven?
- DannyBee 8y ago"And even worse, it's generating worse and ridiculously bigger code. So they spend a lot of effort for worse result." GCC aggressively size optimizes cold regions, and LLVM doesn't bother. This would be pretty easy to fix, but outside of binary size, need to prove it actually matters (the test harness here is a pretty darn old CPU) The "don't catch serious problems in build system" is the bigger worry, imho.
- hubicka 8y agoI have re-tested on my skylake notebook and updated the blog. It confirms darn old CPU I use as my benchmark machine. Maybe it is bit more sensitive to the difference which is expected for non-server CPU. GCC does "almost full LTO" with partitioning, while clang does thinLTO that does make most of code size/speed tradeoffs without considering whole program context, so it may be interesting to get both alternatives closer in code size/performance metrics. I have got Firefox developer account of level1 and I am looking into official benchmarking architecture which I have now updated to GCC 8 with LTO+PGO.
- froydnj 8y agoRegression testing for performance is checked via several test suites (Talos, for instance, with numerous subtests: https://wiki.mozilla.org/Performance_sheriffing/Talos/Tests https://wiki.mozilla.org/Performance_sheriffing/Talos/Tests) and monitored by our ever-dutiful performance sheriffs (https://wiki.mozilla.org/Performance_sheriffing https://wiki.mozilla.org/Performance_sheriffing).