compilerdev

3 ms·

1.
by compilerdev 8y ago
The article is about the performance of the code generated by Clang/GCC, not the compile time one gets using them. For those interested in compile time scaling with number of cores, below are results from testing I did on Windows 10 wi
2.
by compilerdev 8y ago
Yes, the issue is the LTCG build, which by default uses 4 threads and with Chromium the compiler hits some pathological issues with such a huge program and it ends up using mostly 1 core and swapping lots of memory.
3.
by compilerdev 8y ago
See my other answer in this threaad, the main reason for the strange result is doing an LTCG build, not really the CPU, which scales quite nicely in the Linux tests from Phoronix.
4.
by compilerdev 8y ago
See my answer above, it's because the build was LTCG and in the best case at most 4 cores were used during optimization/code geneation/linking.
5.
by compilerdev 8y ago
Ian Cutress replied on the article comments that LTCG is indeed used. With LTCG those strange results make sense - it's spending a lot of time on just 4 threads by default - actually majority of the time is on one thread for the Chromi
6.
by compilerdev 8y ago
The Chrome compilation looks really strange indeed, especially with having the results from Phoronix on Linux which show that it's the fastest compiling the Linux kernel. I wonder what kind of Chrome build it's doing - does it use
7.
by compilerdev 8y ago
Not to take anything away from this, it's great that such a tool is available, but Microsoft had this kind of technology 20 years ago, known as BBT - still used in some places, but overall systems moved to profile guided optimizations