
Even more fun with building and benchmarking Firefox with GCC and Clang - Twirrim
http://hubicka.blogspot.com/2018/12/even-more-fun-with-building-and.html?m=1
======
kstrauser
This is awesome. I don't have a dog in the GCC-vs-Clang hunt, but I love love
love that the two are leapfrogging each other. It would suck if, say, Clang
were so much better than GCC that they stopped doing cool work on it (and vice
versa). _Everyone_ benefits from this particular friendly competition!

Great job, both teams. Please keep up the great work!

~~~
avuton
FWIW, I doubt the GNU project would stop working on GCC, even if it were
rarely used. GNU Hurd and similar rarely used projects barrel on under the GNU
banner.

~~~
viraptor
The work wouldn't stop, but people would continue to do the same things they
know how to do. Friendly competition gives new ideas. Clang basically forced
nicer error messages on GCC. Sanitizers started with clang and were ported to
GCC.

------
jchw
>I was entertained to noice that Clang actually defines __GNUC__. Shall also
GCC define __clang__?

Pretty unsurprising. Same reason why Firefox and Chrome still identify first
and foremost as 'Mozilla.'

~~~
cordite
The define agent wars have begun

------
kodablah
Not sure if directly related to the article, but curious, if you compare GCC
and Clang and review GCC's logic to improve Clang, have you violated a
license? Similarly if you assume API is copyrightable and covered by the
license, one wonders about violations just reimplementing GCC extensions.
(just spitballing because in general something is not a violation that is not
pursued as such)

------
iheartpotatoes
The author has done some excellent work. I would love to make this kind of
deep-dive compiler / optimization regression part of my own team's continuous
improvement because it is so important to stay on top of, but every time I try
to dive into LTO/PGO it ends up getting deprioritized. Articles like this are
inspiring and informative.

------
g82918
So this may seem like a stupid question, but I have been doing a lot of work
on static compilation for an embedded project, and noticed a huge improvement
from adding -ffunction-sections and -fdata-sections plus link-time garbage
collection with static linking. Would compiling firefox statically against
musl and some static nss provider help?

I sorry if this question is phrased poorly, English is not my first language
and I am new to build system issues.

~~~
nisa
from my limited understand using LTO is a better alternative to -ffunction-
sections and -fdata-sections + gc-sections because the compiler and linker has
more information. Size reductions are often a little bit better for LTO than
for gc-sections. Check this article series:
[https://lwn.net/Articles/744507/](https://lwn.net/Articles/744507/)

------
BoumTAC
as someone not familiar with compilation, what's the purpose of moving from
GCC to Clang ? especially if performance aren't better ? (I think it's what
they are trying to do)

~~~
ajuc
Clang has much better error reporting and warnings. It's maybe not enough to
switch completely, but worth it to compile in both compilers to catch more
bugs. Then you can still release the binaries that are faster and throw away
the binaries that are slower.

~~~
loeg
Firefox isn't moving to build with both, though — it's moving to Clang
exclusively. It will not get the best of both worlds.

------
nixpulvis
Mostly offtopic: I find it ironic this website doesn't render well on Firefox
mobile. :(

The page won't let me zoom all the way out.

~~~
hubicka
It is Google's blogger.com. I am not very advanced user of it and generally
just use whatever it provides for me.

The link is off. This link [http://hubicka.blogspot.com/2018/12/even-more-fun-
with-build...](http://hubicka.blogspot.com/2018/12/even-more-fun-with-
building-and.html) renders better in general.

PS: I found it too ironic to mention in the blog, but I had to uninstall
mobile firefox to get the two-level application needed to submit a patch :)).
For some reason Google authentificator requires over 30MB to take a picture of
bar code.

~~~
nixpulvis
Well, better published than nothing. I found the writeup very interesting and
informative. Looking forward to seeing where this all leads.

------
nickysielicki
I've been having too much fun the past week or so with my new computer and
gentoo --- ldd as my linker, thin LTO, clang 7.0.1 building everything by
default. There's far less breakage than you'd imagine.

------
bonzini
It's ironic that Mozilla evangelizes against browser monoculture, while at the
same time Firefox is increasingly using a language that has supports one
frontend (rustc) and one backend (LLVM) only, and it is degrading support for
all C++ compilers except one.

~~~
nv-vn
This is such an apples-to-oranges comparison that I can't really see how you'd
come to that conclusion unless you were already biased against
Rust/LLVM/Firefox coming into it. Mozilla is against all browsers, i.e. every
single piece of software that can be used to connect to the world-wide web--
the most important and influential piece of technology in the last half
century, being based on the same codebase. The fact that a browser is compiled
by a single compiler is absolutely meaningless, because it still provides
another option over other compilers. This doesn't have any bearing on the
browser monoculture, and it has no bearing on C++/gcc's feasibility because
there are still a thousand other compilers and projects not affected by this.
The fact that Rust only works in one compiler is also pretty meaningless
because that's not the problem Firefox set out to fix.

And say Mozilla did care about what compiler they were using because it locks
them into one of them. They would go ahead and develop a new alternative Rust
compiler with an alternative backend. Oh no! They're all using Glibc still!
And GTK+! And the X.org monoculture!!!

The current goal behind Firefox is to provide an alternate browser that isn't
based on Webkit, not to make sure that every piece of software is equally
competitive.

