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