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
…
gcc version 4.6.1 (GCC)

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

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
…

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
ta...@lpthe.jussieu.fr





Reply via email to