#45308 closed defect (worksforme)
clang-3.4 unexplicably slow
Reported by: | RJVB (René Bertin) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.3.1 |
Keywords: | Cc: | jeremyhu (Jeremy Huddleston Sequoia), cooljeanius (Eric Gallager) | |
Port: | clang-3.4 |
Description
This has already been discussed and confirmed on MacPorts-Users:
clang-mp-3.4 is unexplicably slower than e.g. gcc-mp-4.8 on OS X 10.6.8 (and that gcc instance seems to compile at the expected speed, not slower), while almost the same version shipped by Apple is *significantly* faster than gcc-mp-4.8 on OS X 10.9 . Clang-3.4 as provided for Ubuntu (14.04) is also considerably faster than gcc-4.8 on that platform.
What is going on here?
Change History (7)
comment:1 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Resolution: | → worksforme |
---|---|
Status: | new → closed |
comment:2 Changed 10 years ago by RJVB (René Bertin)
From the thread on MacPorts-Users , called "clang's build performance"
port clean rekonq ; time port -v destroot rekonq # uses Apple's gcc-4.2 on OS X 10.6.8 2:59 total_time port clean rekonq ; time port -v destroot rekonq configure.compiler=clang # uses Apple's clang-3.0 on OS X 10.6.8 1:42 total_time port clean rekonq ; time port -v destroot rekonq configure.compiler=macports-clang-3.4 4:04 total_time port clean rekonq ; time port -v destroot rekonq configure.compiler=macports-gcc-4.8 2:22 total_time A comparable comparison on my Linux netbook (dual core AMD C60 cpu; `debian/rules clean ; time debian/rules install` in the Ubuntu 14.04 rekonq package source). Using gcc-4.8: 669.665 user_cpu 55.457 kernel_cpu 19:34.14 total_time 61.7%CPU {0W 0X 0D 0K 181844M 23F 4669330R 3615500I 544928O 0r 0s 0k 65267w 773771c} Using clang 3.4: 595.714 user_cpu 44.989 kernel_cpu 16:43.17 total_time 63.8%CPU {0W 0X 0D 0K 110304M 314F 3911531R 2632925I 239908O 0r 0s 0k 78230w 570316c}
I cannot answer why, but I can confirm what you have seen. Even on OSX10.9, where the system clang is MacBookPro ~ > clang -v Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.3.0 Thread model: posix So I would guess closer to MacPorts clang 3.4 than it is on OSX10.6, build with the system clang is significantly faster than MacPorts…
I have also observed the regression in compilation speed. Which is not really surprising: GCC was slower, but producing better code (at least on my project). Now clang is catching up on the quality of the produced code, but that does require more compilation time.
So even on the same machine running the same operating system (10.9.x), clang-mp-3.4 is slower than Apple's 3.4-based clang. To me that reeks more of a difference the way the compiler is built than as a bug in llvm ... If clang weren't faster than gcc on Linux I'd almost think Apple were keeping a performance tweak for their own version.
This remind me a bit of the situation with gcc in the PowerPC days, where the same gcc version was very noticeably slower on OS X on a PPC machine that was otherwise considerably faster than the i386 Linux hosts I had access to at the time. (This wasn't just with Apple-provided gcc versions, but also with a self-built gcc 4.0.x built with full optimisation flags.)
comment:4 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Apple clang-3.0 is considerably different than OSS llvm-3.4.2
As for differences in speed, do you have the assertions variant enabled?
comment:5 follow-up: 7 Changed 10 years ago by RJVB (René Bertin)
Yes, Apple clang-3.0 was just there to show that at some point it time there was indeed a clang compiler that was faster than its contemporary gcc sibling. The real comparison is OSS llvm 3.4.2 vs. the Apple build of the same vs. gcc-4.8 . That latter compiler shows that recent (and much more capable) OSS compiler versions can be faster than the older Apple variant.
> port installed llvm-3.4 clang-3.4 The following ports are currently installed: clang-3.4 @3.4.2_1+analyzer (active) llvm-3.4 @3.4.2_0 (active)
I might be interested to pull in clang-3.5 and see how things go with that version, but not if that requires hours of building with dubious outcome ...
comment:6 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)
I wouldn't really consider gcc "much more capable" ... IMO, clang and llvm are MUCH more capable than the antiquated gcc and carry a much less restrictive license. But that's not really the point.
comment:7 Changed 10 years ago by RJVB (René Bertin)
Replying to rjvbertin@…: llvm 3.4.2 vs. the Apple build of the same vs. gcc-4.8 . That latter compiler shows that recent (and much more capable than gcc-4.2) OSS compiler versions can be faster than the older Apple variant.
T,FTFY
[OT] I tend to evaluate a compiler on the performance of the products built with it. And from that POV, clang/llvm have been playing catch-up with that "antiquated gcc". I have no experience with clang's auto-vectorisation optimiser, but up to and including clang-3.3 gcc yielded binaries that were faster on just about all serious computational tasks (I've seen its tree-vectoriser blow a hand-coded SSE2 algorithm out of the water). OT
Do you have statistics? Spindumps? In any event, somethng like this should be dealt with by http://www.llvm.org/bugs