Emacs and LLDB

Posted Feb 13, 2015 20:51 UTC (Fri) by mbunkus (subscriber, #87248)
In reply to: Emacs and LLDB by pizza
Parent article: Emacs and LLDB

I'm regularly compiling my C++ application (MKVToolNix) with both gcc and clang. Just for the heck of it I've just timed full builds with both compilers in order to put hard numbers to my gut feeling. I usually compile with seven parallel processes (on a six-core machine), but this time I've limited it to one process.

Both compilations use the very same settings, most notably among them with debugging options enabled, tons of warning messages enabled (and a select few disabled) and without any of the optimization options. All of this is running on a full up-to-date 64bit Arch Linux system which usually has the latest and greatest releases.

Without further ado here are the numbers as recorded by a simple »time …«:

gcc 4.9.2: 29m 24s
clang 3.5.1: 15m 18s

I haven't compared run time differences. First, this is about compilation speed, and during development compilation speed is the main bottleneck, so getting it down as much as possible is important. And second, the application itself is almost always I/O bound and not CPU bound.

Not saying that clang is better. But it sure as hell is faster. And I even though gcc has improved a lot I still prefer clang's error and warning messages.

Emacs and LLDB

Posted Feb 13, 2015 20:57 UTC (Fri) by pizza (subscriber, #46) [Link] (1 responses)

Can you provide the compiler flags you're using for both? I don't doubt your results, but it would be nice to see the flags that led to them.

Emacs and LLDB

Posted Feb 13, 2015 21:43 UTC (Fri) by mbunkus (subscriber, #87248) [Link]

Sure, here you go (I'll leave out the include flags and some -Defines that only affect installation paths and such):

clang++ -std=c++11 -Wall -Wno-comment -Wfatal-errors -Wnon-virtual-dtor -Woverloaded-virtual -Wextra -Wno-missing-field-initializers -Wno-mismatched-tags -Wno-self-assign -Qunused-arguments -g -DDEBUG -D_FILE_OFFSET_BITS=64 -pthread -c -MMD -MF … -o … …

g++ -std=c++11 -Wall -Wno-comment -Wfatal-errors -Wnon-virtual-dtor -Woverloaded-virtual -Wextra -Wno-missing-field-initializers -Wlogical-op -g -DDEBUG -D_FILE_OFFSET_BITS=64 -pthread -c -MMD -MF … -o … …

Emacs and LLDB

Posted Feb 13, 2015 21:47 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (4 responses)

Clang is not universally faster:

ParaView (default settings with GCC):
ninja 3773.03s user 665.47s system 770% cpu 9:36.07 total

(default settings with CC=clang CXX=clang++):
ninja 4597.47s user 484.16s system 755% cpu 11:12.89 total

Builds were run with an otherwise-idle system, nuking ccache before each run. Versions:

clang-3.5.0-6.fc21.x86_64
gcc-4.9.2-1.fc21.x86_64

Emacs and LLDB

Posted Feb 17, 2015 13:54 UTC (Tue) by nix (subscriber, #2304) [Link] (3 responses)

If ccache is involved, take it out of the equation entirely. It slows both clang and GCC by different amounts when the cache is not hit, and will spoil your benchmarks.

Emacs and LLDB

Posted Feb 17, 2015 14:06 UTC (Tue) by mbunkus (subscriber, #87248) [Link]

I do use ccache and am aware of its effects. All of my compilation runs where done with CCACHE_DISABLE=1.

Emacs and LLDB

Posted Feb 17, 2015 14:50 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (1 responses)

I'll run again without ccache, but seeing as I do use it, the difference isn't ignorable.

Emacs and LLDB

Posted Feb 19, 2015 0:38 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

Closer, but still not good enough (gcc+ccache is faster than clang with or without, so I know which one I'll be preferring for the near future yet):

GCC:
ninja 3505.65s user 616.39s system 769% cpu 8:55.85 total

Clang
ninja 4291.07s user 393.77s system 778% cpu 10:01.92 total

Now if GCC could just use less system time like clang. Though, to be fair, GCC was run first then Clang, so that could be the warming up of the file cache by GCC during the Clang run (which doesn't help Clang's side here).