I test Boost libraries mostly on Windows using various version of gcc 4.3 and up, VC++ 8.0 and up, and the latest version of clang which I build from source using mingw/gcc-4.8.1 in release mode.
While clang is a great compiler when it comes to testing code, getting intelligent error message, and implementing the latest C++ standard, it is noticably slower ( 2x or 3x at minimum ) than the other compilers I use.
The clang command line parameters usually being used are usually along the lines of:
-c -x c++ -O0 -g -fno-inline -Wall -g -march=i686 -m32
with the addition of 'std=c++11' occasionally depending on the test.
Does anybody have any idea why clang is so much slower than any of the other compilers I use ? It does not seem to matter whether it is in C++03 mode or C++11 mode, it is noticeably slower than the other compilers.
You said you configured in release mode, but assertions might still be on. That accounts for a 2x slowdown. Otherwise I’d say that we haven’t profiled and optimized clang on windows very much.
LLVM_ENABLE_THREADS means that clang itself is thread-safe which may be important if you use it as a library but not as a command line compiler. It has nothing to do with clang output. With LLVM_ENABLE_THREADS there is some mutex overhead which may be neglible.
You said you configured in release mode, but assertions might still be
on. That accounts for a 2x slowdown.
LLVM_ENABLE_ASSERTIONS is off.
Can you run it in a profiler and tell us what's slow about it for your benchmark? We don't have a lot of information to work with here. A flame graph would probably be the most useful.
You said you configured in release mode, but assertions might still be
on. That accounts for a 2x slowdown.
LLVM_ENABLE_ASSERTIONS is off.
Can you run it in a profiler and tell us what's slow about it for your
benchmark? We don't have a lot of information to work with here. A flame
graph would probably be the most useful.
I never met a code profiler I liked ( Rogers Will, aka myself ).
Care to recommend one with decent instructions which I can actually use/understand to profile the clang++.exe when I try to compile a test of a particular Boost library ?
Is it possible that the general slowness of clang on Windows targeting gcc comes from some CMake build parameter ? I notice a ton of them for llvm/clang when I use the CMake GUI to configure and generate my clang build. It seems that a number of them are turned on by default. Perhaps many are not necessary. I also find it very difficult to find any documentation about the llvm/clang build parameters. Are there page(s) that document what they are and why they should be used ? For instance I see that CLANG_ENABLE_ARCMT and CLANG_ENABLE_STATIC_ANALYZER are on by default. Could either of these be slowing down the clang compile considerably ? Likewise for llvm I see that LLVM_ENABLE_BACKTRACES, LLVM_ENABLE_CRASH_OVERRIDES, LLVM_ENABLE_PEDANTIC, LLVM_ENABLE_PIC, LLVM_ENABLE_TERMINFO, LLVM_ENABLE_TIMESTAMPS, LLVM_ENABLE_WARNINGS, and LLVM_ENABLE_ZLIB arw all on by default. Can either of these be slowing down clang ?
In general, we see clang being faster than gcc on linux/mac, and about as fast as cl.exe on windows on our bots. It sounds like you don’t configure your build correctly. (clang-built-by-clang is a bit faster than clang-built-by-cl on windows; I don’t know how clang-built-by-clang and clang-built-by-gcc on windows compare. But if you’re seeing a 2-3x slowdown, you’re probably accidentally doing a debug build of clang somehow.)
Another thing to consider is that clang-cl doesn’t implement /MP, the cl flag for multiprocessing. If you are comparing cl with MSBuild to clang-cl MSBuild, clang will go slower because it doesn’t run multiple compiles in parallel.
This, however, doesn’t explain the 2x slowdown vs gcc from Edward’s experimentation. So far all we have are theories on that.
