Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 Jun 2012 16:43:31 +0200
From:      Michel Talon <talon@lpthe.jussieu.fr>
To:        FreeBSD Questions <freebsd-questions@freebsd.org>
Cc:        Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl>, David Brodbeck <gull@gull.us>
Subject:   Re: Why Clang
Message-ID:  <402199FE-380B-41B6-866B-7D5D66C457D5@lpthe.jussieu.fr>

next in thread | raw e-mail | index | archive | help

--Apple-Mail=_22F47BFB-6755-4DB6-BF8A-8A64170FE97B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

David Brodbeck said:
> Another way of looking at it is after 25 years of optimization GCC is
> unable to beat a new compiler that's had almost none...
Unfortunately this affirmation is blatantly false, recent gcc produce =
code
much faster than clang. I give here an example which i like, a monte =
carlo computation for a spin lattice.
Everything runs on my macbook.

lilas% clang -v
Apple clang version 2.1 (tags/Apple/clang-163.7.1) (based on LLVM =
3.0svn)
Target: x86_64-apple-darwin11.4.0
lilas% clang -O4 test.c -lf2c
lilas% time ./a.out
...

real	0m2.359s
user	0m2.341s
sys	0m0.003s

lilas% /usr/local/bin/gcc -v
=85
gcc version 4.6.1 (GCC)

lilas% /usr/local/bin/gcc -O3 test.c -lf2c
lilas% time ./a.out
=85

real	0m1.241s
user	0m1.234s
sys	0m0.003s

So gcc gives an executable running twice faster than clang, basically, =
when both compilers
are run at maximal optimization. To show the effectiveness of the =
optimizer, here is the running
time without any optimization:

lilas% /usr/local/bin/gcc  test.c -lf2c
lilas% time ./a.out
=85

real	0m6.895s
user	0m6.889s
sys	0m0.005s

What this demonstrates is that for programs which do real computations, =
optimization is
*very* important, and gcc is now very good (i have not shown the numbers =
but they match the Intel compiler)
while clang is at the level gcc was ten years ago. So i fully agree with =
Wojciech Puchar, the move to clang
is only driven by anti GPL propaganda which is frankly completely =
stupid, since in any events, gcc
does not contaminate the binaries it produces (except when using =
contaminated accompanying libraries
e.g. for C++). Of course, when compiling FreeBSD kernel or similar =
programs which do little computation
there is no harm using clang. I suspect that the price is higher for =
programs like mencoder which require
the highest efficiency.

I will not comment on the better error messages coming from clang, this =
could be a more serious argument.

--

Michel Talon
talon@lpthe.jussieu.fr






--Apple-Mail=_22F47BFB-6755-4DB6-BF8A-8A64170FE97B--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?402199FE-380B-41B6-866B-7D5D66C457D5>