Emacs and LLDB

Posted Feb 13, 2015 21:47 UTC (Fri) by mathstuf (subscriber, #69389)
In reply to: Emacs and LLDB by mbunkus
Parent article: Emacs and LLDB

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