Why Clang

Robert Bonomi bonomi at mail.r-bonomi.com
Mon Jun 18 20:14:23 UTC 2012

> From owner-freebsd-questions at freebsd.org  Mon Jun 18 11:39:03 2012
> Date: Mon, 18 Jun 2012 18:37:55 +0200 (CEST)
> From: Wojciech Puchar <wojtek at wojtek.tensor.gdynia.pl>
> To: Mark Felder <feld at feld.me>
> Cc: freebsd-questions at 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. 

More information about the freebsd-questions mailing list