Clang on Windows targteing gcc compiles very slowly

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.

How are you building clang? I suspect that you’re using a debug build of clang, which is quite slow.

"which I build from source using mingw/gcc-4.8.1 in release mode."

Try to -DLLVM_ENABLE_THREADS:BOOL=OFF. Might not make a big difference.

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.

Try to -DLLVM_ENABLE_THREADS:BOOL=OFF. Might not make a big difference.

Does this mean thread support in clang itself ? I need thread support in clang as I compile multi-threaded source.

You said you configured in release mode, but assertions might still be
on. That accounts for a 2x slowdown.

LLVM_ENABLE_ASSERTIONS is off.

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.

Jon

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 ?

I just noticed that assert is turned on even in Release on Windows
Is that on purpose? (seems like a bug to me)

Anyway if I build clang with “LLVM_ENABLE_ASSERTIONS:BOOL=OFF” the build get stuck at verifier.cpp from LLVMCore. CL.exe is stuck in an infinite loop.

I am using MSVC 2013 Update 5.

Can you post the cmake invocation you use?

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.)

use Intel VTune (Trial runs for 15/30 days - https://software.intel.com/en-us/intel-vtune-amplifier-xe/try-buy) - very easy to use

im using the cl-clang vstudio plugin binary from the homepage and it compiles slower (nearly 2 times i think) then cl

Huh, that's surprising. Do you happen to
have VS2013 too? What are you
compiling? Anything open-source?

just VS2010 - and a very closed source project, 5 libs, ~50-100kLOC, around 1200 Warnings (legacy code)

latest Xerces C++ is another example (does not fully link under cl-clang) - some warnings
svn co https://svn.apache.org/repos/asf/xerces/c/tags/Xerces-C_3_1_2
VC2010: ~1:59min
cl-clang: stopped at ~6:15 with link error

or latests DosBox (gives compiler bug report) - many warnings
VC2010: ~1:25
cl-clang: stopped at ~3:19 with compiler-bug report

it seems that the cl-clang guys should do compiletests against more dirty projects - not against
the super-clean chrome sources :slight_smile:

another example: https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledCPlusPlus

compiles in a minute in VS2010 - take years with cl-clang, with compile-bug reports in cl-clang

so my "dirty" testbase for finding speed difference and bugs in cl-clang would be

-Xerces C++ 3.1.2 (SVN Tag)
-DosBox (latest SVN)
-RuntimeCompiledCPlusPlus (lastest Git)
-ScummVM (SVN)

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.

Edward, could you time the snapshot binaries from http://llvm.org/builds/ ?

when i disable multi-thread compile and /MP (http://blogs.msdn.com/b/visualstudio/archive/2010/03/08/tuning-c-build-parallelism-in-vs2010.aspx)
i get ~1:12 versus ~1:20 - so that doesn't explain the better speed of VS

How and with what ?