discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: clang vs gcc 4.7


From: David Chisnall
Subject: Re: clang vs gcc 4.7
Date: Sun, 3 Mar 2013 12:56:54 +0000

I am quite obviously biased in favour of clang, however, in the interests of 
fairness:

On 3 Mar 2013, at 11:51, Tom Davie <tom.davie@gmail.com> wrote:

> Clang runs faster in -O0 mode.

I believe this is still true, which helps with a fast compile-test-debug cycle.

> Clang produces faster code in -O3/-Os mode (especially for objc).

Usually there isn't much in it (under 10% often under 5%), however:

- Clang has no support for OpenMP, which means gcc can often compile code with 
OpenMP paths to run n times faster (where n is the number of CPUs in your 
system) than clang.  I've not seen any ObjC code that uses OpenMP, but that 
doesn't mean there isn't any.

- As of last week, clang's autovectoriser is outperforms GCC's at linpack, 
however in the 3.2 release there is no autovectoriser.  For certain 
mathematical code, this means that gcc 4.7 is 2-4 times faster than clang 3.2.  

> Clang produces better error messages.

This is true, however gcc 4.8 has had a massive overhaul of the error 
reporting, so the difference is not as pronounced as it was.

> Clang will be updated in the future with all of apple's changes to 
> objective-c.

Additionally, clang supports several things that gcc doesn't:

- The non-fragile ABI
- Using the faster message send mechanism in libobjc2 >= 1.6 (roughly 10% total 
code size reduction, approximately 50% faster message sending)
- ARC (this, for me, is a killer feature.  Objective-C without ARC just feels 
painful.  It took about 2 hours of using it to get to that stage)
- The ugly and braindead literal syntax that some idiots at Apple thought was a 
good idea.

Clang also includes things like the static analyser and the ARC migration tool.

> Clang is more friendlily licensed (not that I want to start a flamewar, and I 
> realise this argument may not be strong on this particular list).

This is only useful for people embedding clang in other things, however the 
layering in clang is also cleaner, so it is easier, for example, to use clang's 
parser in other things.  In Étoilé, we have SourceCodeKit, which uses the clang 
parser to cross-reference and syntax highlight Objective-C code.

> Clang's codebase is easier to work on.

Not relevant to most people on this list, but definitely true.  This is why I 
got involved with clang in the first place - it was easier to completely 
implement Objective-C code generation support (for two Objective-C runtimes) in 
clang than it was to add support for declared properties to gcc, from a point 
of having no experience with either codebase.

> Clang supports being used as a library, and hence can have other tools (e.g. 
> google's refactored, or the static and (in early development) dynamic 
> analysers) built upon it.

It is also used for header parsing by LanguageKit, which allows easy calling of 
C code from Smalltalk.  

> Clang's C++ support is better than gcc's.

This is especially relevant for Objective-C++, for two reasons:

- Clang has significantly better support for mixing Objective-C and C++ 
exceptions.  When compiling with -fobjc-runtime=gnustep-1.7 and the trunk 
version of the runtime, all of the known corner cases work, including the one 
that causes a segfault in Apple's runtime.  Most of them cause stack corruption 
or crashing with gcc.

- In Objective-C++11 mode, clang's return type inference interacts nicely with 
the auto keyword, so you can do things like:

        auto foo = [NSMutableArray new];

And the type of foo will be inferred to be NSMutableArray*.

On the other hand, this is completely irrelevant to people not using 
[Objective-]C++.

In terms of cross-platform support:

- Clang's exception support is broken on ARM (on my to-do list, but not a high 
priority.  Some Linaro folks are working on it though).  Aside from that, clang 
generally generates better ARM code than GCC (ARM, Apple, Linaro, Qualcomm and 
so on are investing a lot in LLVM and Clang).

- Clang's PowerPC and MIPS support is relatively immature.  I am actively 
working on MIPS, but I wouldn't yet recommend using it in production.

- Clang has no support for m68k or a number of other less-popular 
architectures.  The SPARC support is pretty limited and largely unmaintained.  
IA64 support was recently dropped.

- Clang is the default system compiler in FreeBSD, gcc is the default system 
compiler on most Linux systems (although Android is in the process of 
switching).

David


-- Sent from my STANTEC-ZEBRA




reply via email to

[Prev in Thread] Current Thread [Next in Thread]