On 8/19/2016 2:09 PM, Jeffrey Walton wrote: >>> But hopefully slightly less self serving. >> To be honest, it doesn't seem an unfair characterization to me. >> >> GCC could highlight the ethical and tit-for-tat benefits of the GPL, but I >> guess they do not see those as a benefit. >> >> GCC has also the benefit of being a more mature code base and, as a result, >> it has been more thoroughly tested in a wider range of codes; yet this is >> difficult to quantify and arguably Clang is more widely used today than GCC, >> just not in Linux, thus this might not be true anymore. > GCC does a much better job of optimizing. I run benchmarks for some > libraries regularly to ensure there are no regressions. GCC is > consistently 2x faster than Clang, and GCC is on-par with ICC. > > It seems the slow-down is the treatment of const-expr's. Under the > laws of the physical universe as we know them, some values are fixed > at compile time won't change (regardless of their const-expr status). > GCC optimizes them (common sense), while Clang does not (expected to > somehow change). > > That little slow down adds up, and it makes us do things like avoid > std::numeric_limits<T>::max() in favor of a #define instead. More > complex examples include propagating a constant using a template > parameter instead of a function parameter. GCC will realize a constant > does not change under the laws of the physical universe as we know > them; while Clang will treat the constant passed as a parameter as > something that can miraculously change after saving the source file. > > Jeff There are many situations where gcc optimizes better, and a few where clang is better. Among the latter is min| max reduction, where clang can "riffle" by batching more than one simd parallel reduction so as to overcome latency. The implied point is valid, that many users can suffer a little more compile time in order to improve run time. -- Tim Prince
