Date: Mon, 18 Jun 2012 15:14:31 -0500 (CDT) From: Robert Bonomi <bonomi@mail.r-bonomi.com> To: freebsd-questions@freebsd.org Subject: Re: Why Clang Message-ID: <201206182014.q5IKEVdQ014212@mail.r-bonomi.com> In-Reply-To: <alpine.BSF.2.00.1206181829210.99007@wojtek.tensor.gdynia.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
> From owner-freebsd-questions@freebsd.org Mon Jun 18 11:39:03 2012 > Date: Mon, 18 Jun 2012 18:37:55 +0200 (CEST) > From: Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> > To: Mark Felder <feld@feld.me> > Cc: freebsd-questions@freebsd.org > Subject: Re: Why Clang > > >> I don't say clang is just bad, but i prefer real data over hype. > > > > This is the most memorable and impacting set of graphs that I remember. I > > haven't followed the data much since. > > > > http://clang.llvm.org/performance-2008-10-31.html > > > > Now imagine having to rebuild projects constantly during your dev cycle. The > > time savings is going to add up quick. > > still not read my mail where i actually compared it in real. or don't > want? > > I really don't care about cool graphs but at facts for me as a USER (not > developer) of C compiler. > > And the facts are: Lots of worktime were spent to make new C compiler from > scratch and this resulted with thing 5 times larger, *YOUR* measurement of sizes was faulty. <grin> > working at similar > speed and producing similar code to GCC that is already considered bloat. > The truth is sad. Starting from fresh and not being able to beat 25-year > old bloated gcc is just funny. You _do_ understand that they could not use -any- of the technology implementations in GCC, that they had to redevelop everything from scratch, right? I'm sure that you _also_ are aware that a larger program size does *NOT* necessarily mean 'bloat'. That 'optimizing for speed', which can, and does, result in code that is larger than the unoptimized code, is not 'bloat'. That increasing the clarity of explanations in error messages -- which takes more words -- is not 'bloat'. That additional logic to more precisely identify -what- error occured, and provide a 'better' identification/explanation, compared to just 'parse error near {token}', is not 'bloat'. That writing code for clarity and *maintainability*, even if it incurs some 'cost' in increased size, is not 'bloat'. That doing things the 'long way', rather than the 'short way', because it is necessary for _compete_ compliance with a standard, it not 'bloat'. The fact that this _totally_new_ implementation runs roughly as fast and generates similar quality code to a package that has undergone over two-and-a-half_decades of tweaking and polishing -- well, it is little short of miraculous that it is -that- good, _that_ quickly. Feel free to demonstrate that _you_ can do it better, faster, AND smaller. *WITHOUT* lifting anything from any existing, copyrigthted, code that is.z > That's my view - as a final "consumer", not developer. My view is that > bloatware is replaced by another bloatware, which - because of it's young > age - have greater future potential of bloat than GCC. Obviously, you would then prefer to use a compiler which eliminated the text of all the information/warning/error messages and replaced all those messages with just 'Error: {number}' -- or, even shorter, just 'E{number}' -- which was done in the name of reducing that dreaded 'bloat'. (The reduction in in executable size from this approach can be _surprisingly_ large). Obviously, you would also prefer to use a compiler which 'gave up' and aborted the entire compile after reporting the first fatal error. This will eliminate all that dreaded 'bloat' involved with unwinding the parse state, and all the other 'overhead' stuff you have to do to be able to "sort-of" continue parsing the rest of the source file. > This tens or hundreds of thousands of work-hours could be spent far better > by getting latest gcc available on GPLv2 licence and start from there, That *cannot* be done. There is simply *NO* way to license anything derived from a GPLv3 product under GPLv2. The GPL itself expressly forbids it. Thus, one would have to _start_ with a GPLv2 compiler and *independently* create all the changes/improvements that have been made since that GPLv2 version was released. This is a _far_ bigger project than converting to the use of a different, but _more_standards_compliant_, compiler.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201206182014.q5IKEVdQ014212>