Also, in my experience, it is much easier to install another clang version than another gcc version on Linux (gcc is more or less married to a given libstdc++ version, AFAICT).
Regards Antoine. Le 22/06/2020 à 09:06, Uwe L. Korn a écrit : > With my conda-forge background, I would suggest to use clang as a performance > baseline, because it's currently the only compiler that works reliably on all > platforms. Most Linux distributions are nowadays built with gcc, also making > a strong argument, but on OSX and Windows the picture is a bit different. > > Linux: One can use gcc or clang, as long as you use the right flags, they are > interchangable. > macOS: There are gcc builds but I have seen in recent time people solely > using clang, either the one coming with Xcode or a newer build. > Windows (MSVC-toolchain): You can use MSVC or clang, while most people prefer > MSVC, clang is well-tested (e.g. Chrome uses it) > Windows (MSYS2-toolchain): Mostly uses GCC but clang is also supported. There > were some informal mentions that clang performs better here when using AVX2. > > Cheers > Uwe > > > On Mon, Jun 22, 2020, at 6:27 AM, Micah Kornfield wrote: >> There has been significant effort recently trying to optimize our C++ >> code. One thing that seems to come up frequently is different benchmark >> results between GCC and Clang. Even different versions of the same >> compiler can yield significantly different results on the same code. >> >> I would like to propose that we choose a specific compiler and version on >> Linux for evaluating performance related PRs. PRs would only be accepted >> if they improve the benchmarks under the selected version. Other >> performance related PRs would still be acceptable if they improve >> benchmarks for a different compiler as long as they don't make the primary >> one worse and don't hurt maintainability of the code. I also don't think >> this should change our CI matrix in any way. >> >> There are other variables that potentially come into play for evaluating >> benchmarks (architecture, OS Version, etc) but if we need to limit these in >> a similar way, I think they should be handled as separate discussions. >> >> I'm not clear on the limitations that our distributions place on compilers, >> but ideally we'd pick a compiler that can produce most/all of our binary >> artifacts. >> >> Could someone more familiar with the release toolchain comment on good >> options to consider? >> >> Any other criteria we should consider? Other thoughts? >> >> Thanks, >> Micah >>
