On Tue, 20 Mar 2007, Nicholas Nethercote wrote:
GCC is a very ambitious compiler:
- it supports a lot of platforms
- it supports a lot of languages
However, most users do not use most of those combinations. The problem is
that supporting all these combinations hurts the specific combinations.
Nobody responded to this particular point, which surprised me. I looked up
the GCC mission statement (http://gcc.gnu.org/gccmission.html). It has the
following "Design and Development Goals"
* New languages
* New optimizations
* New targets
* Improved runtime libraries
* Faster debug cycle
* Various other infrastructure improvements
I think they're terrible:
- "New languages" -- why? Just because you can? In theory, adding a new
language can be free, but in practice it never is.
- "New optimizations?" I assume this means "optimization passes".
Users don't care about optimization passes. Users care
about performance. Optimizations happen to be the main way to achieve
that, but substituting the mechanism for the end goal in a mission
statement sends the wrong message.
- "New targets" -- this one is better, but some qualification would help.
I understand that the goal is for GCC to be the universally available
compiler, but it could be clarified that it's targets that are desired by
users.
- They're vague -- "improved runtime libraries"? "various other
infrastructure improvements"? These phrases are meaningless. Why not
just write "a really awesome compiler"?
- There's no notion that you can't have everything. For something to be a
high priority, you have to make something else a lower priority. This
list is just "faster! better! more!" In particular, to return to the
original point of this thread, the "faster debug cycle" has been suffering
horribly (due to compile-time performance regressions).
- They haven't been updated since 1999-04-22.
Here are some suggestions for more suitable priorities. They're all
characteristics, rather than features. They're far from perfect, but I
think they're better than the goals above. I haven't put them in any
particular order.
- Correctness w.r.t. language definitions (ie. accept correct code, reject
incorrect code)
- Correctness of the compiler (ie. no compiler crashes)
- Correctness of generated code (ie. compiled code should do the right
thing)
- Performance of the compiler (time and memory)
- Performance of generated code (time and memory)
- Performance of building the compiler (time and memory)
- Support of existing language extensions
- Addition of new language extensions
- Support of existing languages: C, C++, Objective C, Fortran, Ada, Java
(and any others I've missed)
- Support of new languages
- Support of existing platforms (a.k.a. portability)
- Support of new platforms (a.k.a. portability)
- Design and code complexity
- Maintainability
- Debugging support (eg. generating correct debugging info)
- Profiling support
- Quality of error messages (eg. uninitialized variables)
- Support for other extensions (eg. mudflap)
You can split these up or qualify them more, eg. for "performance of the
compiler" you might distinguish between -O0 and -O2.
The key idea is that you can't have all of these. For example, supporting
many languages and platforms increases complexity, adds more code (which
slows down build times), and can hurt performance (as the tree codes example
has shown). It also takes resources that then are not used for improving
other aspects. Another example: there was a suggested SoC project yesterday
for an incremental C++ parser. That could speed up compile-time performance
in some cases, but at the cost of increased design and code complexity.
This idea is simple, and I'm sure many of you understand it individually.
But it appears to me, as an observer of GCC development, that GCC developers
as a group don't understand this.
On Mon, 19 Mar 2007, Doug Gregor wrote:
We have hit a hard limit in the design of GCC. We need to either use
more memory, use more compilation time, re-architect non-trivial
portions of GCC, remove functionality, or come up with something very,
very clever. Pick one, but if the pick the last one, you have to
specify what "something very, very clever" is, because we seem to be
running short on ideas.
Doug was talking about the tree code issue, but this paragraph sums up the
whole situation perfectly. Sometimes it's a good idea to stand back and
look at the bigger picture, rather than just running on the "gotta fix
another bug, gotta add another feature" treadmill.
Nick