Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
I somehow get the feeling that the development of gcc is slightly stagnant (although it admittedly has made huge improvements in some areas, such as link-time optimization), and clang has been catching up at a frightening speed.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
GCC may be on the stagnant side, but it is a lot more polished than clang is. Even though clang is quickly catching up, I still find at times clang is abysmal.
I don't use clang to seriously compile anything, although I do use it for a second opinion when I can't make heads or tails out of GCC's errors. I'd say 80% of the time, clang's diagnostic output is better, 10% of the time GCC is better, and 10% of the time, clang utterly explodes on the source and either crashes or gives utterly bogus output.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Warp wrote:
Nach wrote:
Even though clang is quickly catching up, I still find at times clang is abysmal.
Care to give some examples? I use clang for my payjob every day, and it seems to work fine.
It explodes on various types of code (generally extreme C++). In fact, I can't use clang to compile a single one of my large projects, it doesn't work.
Benchmarking output of several of our libraries, performance is also vastly inferior to GCC.
If you want examples of the latter:
http://insanecoding.blogspot.com/2011/11/how-to-read-in-file-in-c.htmlhttp://insanecoding.blogspot.com/2011/11/reading-in-entire-file-at-once-in-c.html
Also, as one example, my company has our own MD5 implementation in the fastest C and hand tuned assembly we can come up with, output from our benchmarks:
i386:
ASM MT-Unsafe: 622 MB/s
ASM MT-Safe: 575 MB/s
OpenSSL: 566 MB/s
GCC: 505 MB/s
Clang: 478 MB/s
AMD64:
ASM MT-Unsafe: 625 MB/s
ASM MT-Safe: 625 MB/s
OpenSSL: 614 MB/s
GCC: 517 MB/s
Clang: 477 MB/s
We're also in middle of building optimized SHA-2 routines, and right now, we're seeing GCC produce results which are >100MB/s faster than clang.
Warp wrote:
If it has bugs, there is bug reporter, you know?
Yes, but I don't have time to sit down and whittle down the issue to a base problem and report it, especially when I have a perfect working solution. My boss would never sign off on spending a lot of time fixing problems for something inferior which we don't need.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Yes, but I don't have time to sit down and whittle down the issue to a base problem and report it, especially when I have a perfect working solution. My boss would never sign off on spending a lot of time fixing problems for something inferior which we don't need.
But then you are perpetuating the problem you are complaining about, instead of helping the project become better.
(Also, I honestly find your case strange. It's not like clang is used by just an extremely small niche group of hobbyists. It's used literally by millions of people, many making production code, mostly for MacOS X and iOS. I doubt that all of those projects are just small and simple programs.)
Performance results from 2011 are hardly relevant anymore. They do improve the compiler all the time, you know?
(I'm not saying that clang already produces code that's as fast as gcc. I'm just saying that citing data that's almost 3 years old is hardly relevant anymore.)
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Warp wrote:
Nach wrote:
Yes, but I don't have time to sit down and whittle down the issue to a base problem and report it, especially when I have a perfect working solution. My boss would never sign off on spending a lot of time fixing problems for something inferior which we don't need.
But then you are perpetuating the problem you are complaining about, instead of helping the project become better.
I'm not complaining about it, I'm telling you why I don't use clang for anything other than the occasional warning/error decipherment.
Warp wrote:
Also, I honestly find your case strange. It's not like clang is used by just an extremely small niche group of hobbyists.
Extreme C++ isn't all that popular.
Warp wrote:
It's used literally by millions of people, many making production code, mostly for MacOS X and iOS. I doubt that all of those projects are just small and simple programs.
You just identified why it's fine for most people. Those platforms use their own C++ libraries. Linux uses libstdc++ which is already known that clang is unable to handle in some cases.
Warp wrote:
Performance results from 2011 are hardly relevant anymore. They do improve the compiler all the time, you know?
I've reran them recently, I didn't see noticeable improvements to the worse cases highlighted there.
Warp wrote:
I'm not saying that clang already produces code that's as fast as gcc. I'm just saying that citing data that's almost 3 years old is hardly relevant anymore.
It's only irrelevant if it no longer holds true. Unfortunately, my recent tests show that it still does.
I provided these pages so you can see what is being benchmarked, and why I still don't use clang.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
