On Mon, Mar 19, 2007 at 08:16:42PM -0700, Mark Mitchell wrote: > Nicholas Nethercote wrote: > > > As for what is best to do, I don't know. But I do know that complexity > > is bad, and that GCC is very complex. You are absolutely right about > > there being hard limits. There are trade-offs required. Whether the > > current and ongoing trade-offs are the right ones is an open question. > > I do think compilation speed -- and memory use -- is important. > However, I do also think that it's reasonable to measure compilation > speed against workstation speed. Compiling GCC takes me a lot less time > than it did even a few years ago because I have much faster computers.
But the problem is that those days are over. Before 2003, there was a magic number, alpha, that you could vary and it would tell you how to make a new version of your chip from three years ago that would be better in all respects: faster, smaller, lower-power, cheaper. Around 2003, the curves all shifted, because the traditional CMOS scaling formula can no longer be used: atoms don't scale. Once the gate oxide layers get down to a few atoms thick, they leak, and power soars enormously, even when the gate is not switching. Chip designers and EDA companies have gone to heroic extremes to compensate for these effects, and Moore's Law is still alive and kicking. But everything has changed. Processor vendors are compensating for this by giving up on increasing the clock frequency. Instead, they've gone for dual core, then four cores, and the roadmaps show plans for dozens of cores, but the clock frequency isn't going to be higher than it is now. But programmers that have grown up with the way things have been for the last 30 years have gotten spoiled. If your program is bloated and inefficient, no matter; wait a year, and it will get faster all on its own. If you want to be a working programmer in ten years, you need to start thinking about parallel programming. For necessarily-serial programs, there is less room than ever to be sloppy, because you won't recover any speed that you lose.
