Why does Clang compile considerably slower than GCC?

[fberger]

Today I toyed a little with Clang, just to see how it performs with Gentoo and Portage. I am not so much interested in faster binaries, but I'd like to reduce compile times if possible.

I picked a bunch of test packages, ebuild fetched and ebuild unpacked them, then I timed ebuild compile first with sys-devel/gcc-7.3.0-r3 and then again with sys-devel/clang-5.0.2.

To enable Clang, I did the simplest thing and set

Code: Select all

CC="clang"
CXX="clang++"
CFLAGS="-O2 -march=i686 -pipe"
CXXFLAGS="${CFLAGS}"
CFLAGS="${CFLAGS} -fno-lto"              
#XXFLAGS="${CXXFLAGS} -fno-lto"

in make.conf (no-lto since LTO may cause trouble).

To my surprise, Clang took between +28% (app-arch/unzip) and +54% (dev-db/postgresql) more compile time, with a median increase of +40%.

Word has it that Clang compiles faster than GCC in the wild. What could be a reason that it consistently performs so much slower on my machine? Did I forget to set up something that is required? I'll also gladly provide more information.

[1clue]

Disclaimer: I have zero clang experience.

What are your MAKEOPTS? Do you have an appropriate value for -j for your cpu?

[fberger]

I am using MAKEOPTS="-j3"

Code: Select all

$ lscpu
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  2
Core(s) per socket:  2
Socket(s):           1

[1clue]

Try adjusting that value. The handbook says (or used to say) -j was often N+1 where N=number of cores. That would be 5 in your case.

I've played with that value quite a bit, my 8-core atom box has -j12 and that seems to be best, if a bit choppy on response time during the compiles.

While I have no evidence to suggest it might be true, I wonder if clang optimizes better with a different -j value than gcc?

[John R. Graham]

... While I have no evidence to suggest it might be true, I wonder if clang optimizes better with a different -j value than gcc?

The -j option never makes it to the compiler. It's an option to make, controlling how many jobs are dispatched in parallel.

- John

[eccerr0r]

I actually have heard the opposite: that clang was slower on compilation but sometimes produces faster binaries. YMMV in any case.

Most people use clang because they're afraid of GPL but still want OSS.

Gcc has gotten bloated to the max lately... the colored output proves it :D

If you want to reduce compile time, possibly reducing -O2 to -O1 may speed things up too.

[1clue]

... While I have no evidence to suggest it might be true, I wonder if clang optimizes better with a different -j value than gcc?

The -j option never makes it to the compiler. It's an option to make, controlling how many jobs are dispatched in parallel.

- John

Yeah, I guess I knew that at one point. That must have been the brain cell that died last weekend.

[fberger]

I actually have heard the opposite: that clang was slower on compilation but sometimes produces faster binaries. YMMV in any case.

I've checked the interwebs again, and though most results are stale by now, the indeed paint a diverse picture:

• clang-3.4 compiled an Unreal 3 project -54% faster than gcc-4.8.2 (Comments on Hacker News, with the insightful line: "clang used to be much faster at building, but then again the binary was never equally on-par performance wise. As clang is getting better at optimizing, the compilation times are getting more and more similar.")
• clang-3.9.0 compiled Firefox -18% faster than gcc-6.3.0
• clang++-4.0.1 compiled a C++14 library with a lot of templates +10% slower than g++-7.1.0

I am still surprised by the consistent speed difference between GCC and Clang in my setup. I might experiment with different -j settings (since I'm effectively using make) and -O settings.

[pjp]

"the binary was never equally on-par performance wise"

Any findings as to whether or not this has changed?

[John R. Graham]

There are some fairly recent Phoronix benchmarks that show clang edging out gcc is some performance benchmarks (of the compiled code) but with gcc mostly (in the technical >50% sense) still better.

Interesting to note that the compile time on clang which in years gone by was much faster than gcc is slipping as the generated code quality increases.

- John

[fberger]

Any findings as to whether or not this has changed?

No personal ones. The last link in the list has some very detailed statistics on different operations, though, and is currently not too stale.

[Ant P.]

Current versions of clang have severe performance regressions, you're not the first to notice.

[pjp]

There are some fairly recent Phoronix benchmarks that show clang edging out gcc is some performance benchmarks (of the compiled code) but with gcc mostly (in the technical >50% sense) still better.

Interesting to note that the compile time on clang which in years gone by was much faster than gcc is slipping as the generated code quality increases.

- John

I'd be more surprised if that didn't happen, unless that was a goal of the project. I'd also expect fluctuations until they reach some sort of "doneness." For example, comparable results to gcc of x revisions back. Then they have to play catch up from there as opposed to not having achieved comparable results of latest gcc. From what little I've followed, it sounds like they're pretty far from the latter.

The last link in the list has some very detailed statistics on different operations, though, and is currently not too stale.

Thanks, I'll take a look.

[John R. Graham]

I'd be more surprised if that didn't happen, unless that was a goal of the project.

It was a stated benefit of the project: that gcc was fat & slow, that clang by contrast was clean sheet, thus lean & fast.

- John

[pjp]

But have they achieved "version 1" yet? I know it is listed as version 6, but I thought I remember reading that it wasn't possible to rely on it for a complete system build (don't recall if that was Linux or BSD). That to me sounds like it isn't (or wasn't) a finished product.

EDIT:

Not finding anything that looks like what I remember reading, but I am seeing several "big name" references to things moving to LLVM/CLANG in 2017. That seems like a notable milestone for some reason.

EDIT 2:

One issue was not being able to compile Linux the kernel.

[eccerr0r]

Seems like FreeBSD can be completely built with clang now at least for x86, and I suspect they tried hard to achieve this: Because of the license issue, they've been trying hard to get an all BSD-compatible license distribution and the compiler they've been distributing gcc for the longest time only because there was nothing else.

I don't know about NetBSD, they may still require gcc. Seems like some of the NetBSD targets don't like clang yet...

[fberger]

I have asked about the issue on the cfe-users mailing list, and they gave me two pointers:

• Does GCC cache precompiled headers on Gentoo? I.e. do we cache .pch-files somewhere?
• A popular German blogger encountered a similar issue (blog.fefe.de: Wo kommt eigentlich dieses Gerücht her, clang sei so besonders effizient und kompiliere schnell?) and traced it back to Clang loading a ton of shared libraries upon each run. Once he used a static version, Clang compile times were on par with GCC.

I am attempting to build a static LLVM + Clang on Gentoo right now. In case that succeeds, I'll report back with compile times.