"Dependent on" ???
Posted Feb 27, 2007 23:38 UTC (Tue) by nix
In reply to: "Dependent on" ???
Parent article: Mitchell Baker and the Firefox Paradox (Inc)
GCC. This is pretty much your only choice if you want a C/C++ compiler.
Many years ago GCC was a healthy project with lots of progress and
competition (remember EGCS?). Nowadays my impression is that there are
only a handful of developers working on GCC.
I can't really imagine how you could get that impression. I've been
watching the GCC lists since maybe 1998, and while people have left or
hugely cut down their development effort (Zack Weinberg, Matt Austern...)
other developers have piled in. A lot of them. Not random newbies, either:
more years ago than I care to remember, Ken Zadeck invented
representation that GCC is now using.
A quick grep with a vile lashup of shellery reveals
that, in 1998 and 1999 combined, a rough total of 325-odd people appeared
in the GCC changelogs. In 2006 *alone* the same number appear (actually
All these figures are thrown off by typos, UTF-8 canonicalization and
Romanization differences, and so on, so it's hard to say what the actual
numbers are, or how many people have arrived and left the project: but
numbers of developers are definitely not declining, unless the people who
are left are becoming much less capable of spelling their own names.
If we error in the other direction by ignoring unique names that appear
less than ten times in the changelogs (some people with non-ASCII
characters getting short shrift in the process), we get a total of 89
heavy contributors who committed at least ten changes in 1998/1999 (66
contributed in 1999 alone), and 121 who did the same in 2006. That's a
rough doubling of the `heavy developer' base, and comm(1) shows only
25-odd heavy developer names in common. (Some surprising people get left
out of the 1999 list, though, like Jeff Law, who goes through too many
variations on his name for my ugly script to spot, with each iteration
getting less than ten commits...)
(Vile scriptery available on request but it has raw tabs in it so I'm not
sure I can paste it in here. Jon's git-grinder is doubtless much nicer.)
The codebase is big and complicated, and not a lot of people have the
expertise required to contribute. As a result, most of the changes to GCC
in the past few years have been to make it more ANSI compliant,
Oh, boy, you're out of date. The huge push toward (mainly C++)
standards-compliance was a 3.x thing. GCC 4.x added an entire new
intermediate representation (GENERIC/GIMPLE) and dozens of optimization
passes, on a much firmer theoretical base and more pleasant representation
than the ad-hoc RTL stuff that was the only choice for non-frontend
optimizations before that. Before this change, it was horribly diffficult
to pick algorithms out of the literature and use them in GCC. Afterwards,
well, it's still effort, but it's at least
an order of magnitude
and there have been relatively new features or speedups. In fact,
compiling code takes longer than it used to.
You're going to get a nice surprise soon, then, because the tree-ssa
optimizers have finally reached the stage where some of the horrible slow
old RTL optimizers are being removed or drastically simplified, as the
much faster tree-ssa optimizers can supplant them entirely, and take much
less time to do much more work...
As for new features? Let's see, we have gfortran in GCC 4.0, a radically
improved Java implementation in GCC 4.3 (thanks to using ecj as the
frontend), and OpenMP in GCC 4.2... Or do new features not count unless
they're in the C frontend? Oh, btw, the C frontend had its parser
completely rewritten by Joseph Myers in GCC 4.0.)
You probably won't see huge improvements in speed on targets like i386
without someone rewriting the register allocator and reload pass, probably
the most hairy thing left and a creature of a different era. This requires
vast fortitude and an immense ability to pick unstated assumptions out of
pretty much every .md file in GCC. Several attempts have been made: none
have yet succeeded.
I'd say the pace of development in GCC has never been higher. If anything,
it's so high that better tools are needed: patches get lost unreviewed in
the swirl of traffic on gcc-patches too often...
to post comments)