From owner-freebsd-questions@FreeBSD.ORG Tue Jun 19 17:11:06 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DA99E106566B for ; Tue, 19 Jun 2012 17:11:06 +0000 (UTC) (envelope-from ulrich@pukruppa.de) Received: from pukruppa.de (pd95cabe3.dip0.t-ipconnect.de [217.92.171.227]) by mx1.freebsd.org (Postfix) with ESMTP id 479978FC0A for ; Tue, 19 Jun 2012 17:11:05 +0000 (UTC) Received: from pukruppa.de (localhost [127.0.0.1]) by pukruppa.de (8.14.5/8.14.5) with ESMTP id q5JGh5ht069859 for ; Tue, 19 Jun 2012 18:43:07 +0200 (CEST) (envelope-from ulrich@pukruppa.de) Message-ID: <4FE0AC19.5080506@pukruppa.de> Date: Tue, 19 Jun 2012 18:43:05 +0200 From: Peter Ulrich Kruppa User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120618 Thunderbird/13.0 MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: <402199FE-380B-41B6-866B-7D5D66C457D5@lpthe.jussieu.fr> In-Reply-To: <402199FE-380B-41B6-866B-7D5D66C457D5@lpthe.jussieu.fr> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: Why Clang X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 17:11:06 -0000 On 19.06.2012 16:43, Michel Talon wrote: > 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. Really - just to throw in another opinion: As an average user I don't see any performance impact on my clang-built desktop-every-day-workstation. The only thing that is getting on my nerves are some ports I frequently have to rebuild with gcc. It would be nice if the porting team could set up some automagic for that. There seems to be no harm in running a mixed clang/gcc built userland. Some members of this list seem to fear some kind of communist infiltration by gcc - I hope this is no serious issue, is it? > > I will not comment on the better error messages coming from clang, this could be a more serious argument. I don't know what they mean, but they really do look good :-) Greetings Peter > > -- > > Michel Talon > talon@lpthe.jussieu.fr > > > > >