On 11/1/07, Ted Byers <[EMAIL PROTECTED]> wrote: > --- David Miller <[EMAIL PROTECTED]> wrote: > > From: NightStrike <[EMAIL PROTECTED]> > > Date: Thu, 1 Nov 2007 22:34:33 -0400 > > > > > I think what is more important is the resulting > > binary -- does it > > > run faster? > > > > The answer to this is situational dependant. > > > > For example, for me, the speed of compilation at -O2 > > is very important > > because I'm constantly doing full tree build > > regressions. > > > > There are large groups of us who pine for > > compilation to be as fast > > as the old MIPS compilers were, and they were fully > > optimizing > > and even had a more advanced register allocator than > > GCC has now. > > > I find it hard to fathom why the OP would be concerned > with compile and run times measured in minutes and > seconds. I don't know how long your full tree build > regressions take, but for me, a very small application > will take half an hour to compile, and a large one > could take all day. But if by hand tuning my code, > and pushing my development tools to their limits, I > can have my application finish a task in minutes where > my predecessors' versions took hours (something I > commonly see, perhaps by chance, with the projects I > find myself working on), the savings of my clients' > users' time is greater than the cost of my time by > several orders of magnitude, so I don't mind waiting > for a build to finish if the end product is provably > correct. > > There is much more to both compile time and run time > performance than how fast your development tools are. > I expect more recent tools to take longer than the > tools I used even five years ago, simply because there > is much more for them to do; and as they get better, I > can use more demanding parts of the language (my > preferred language is C++) that simply weren't > practical a few years ago. As I do this, then my > tools must work harder still. It isn't only the > tools, but what you do with them ... > > If I may state the obvious, an outstanding programmer > can easily make a mediocre development tool look good, > while a mediocre programmer can make even the best > tools look very bad. That said, I often download open > source applications (all good quality), and the GCC > suite takes longer to build than all the rest combined > (that is, of the ones I download), and since that > finishes in but a few hours on my machine, I won't > worry about how fast gcc compiles code until it takes > many days to compile itself. :-) > > As you say, performance questions and answers depend > on the situation. But I say, the single most > important question is, "Is the code correct?" that > is, does it produce output that is provably correct. > There is no point in having an insanely fast program > if it only, or even only generally, produces garbage. > As important as performance is, the correctness of the > code is, to my mind, infinitely more important than > either compile or runtime performance! > > I would encourage the good folk who work on GCC to > focus on making the code correct first, and only after > that can be proven, worry about making it faster. > Really bad things can happen to real people if my > programs give incorrect results (think about things > like contaminant transport, dose/risk assessments, > &c., and how someone I have never met may suffer if my > application gives a consultant or civil servant > unreliable results). When you think about the things > relevant to the work I do, you will understand why I > don't care if my build times are measured in hours or > days or even weeks as long as my clients' users' can > work more efficiently and obtain provably correct > results from my programs. Computers are cheap these > days, so if I find myself too often waiting for a > build to complete, I'l just get another computer to > work on while I wait for the one doing the build to > finish. > > I don't help develop GCC, but may I express to those > that do that I apreciate their efforts.
I agree with you 100%. It has always been my view that if you can't compile fast enough, then get another machine and use distcc, or get a quad core and do make -j5, etc etc. Compile time should never outweigh code correctness, and if it takes longer to compile more correct code, then that's just the nature of moving forward into the future.