"Dependent on" ???

"Dependent on" ???

Posted Feb 27, 2007 23:38 UTC (Tue) by nix (subscriber, #2304)
In reply to: "Dependent on" ??? by eklitzke
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 the SSA 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 326). 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 less.

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...

---

(Log in to post comments)