Re: How Smart Can We Afford to be?

>> In article 92-02-046 jjones@uiuc.edu writes:
>>6. Can sophisticated optimizing compilers be built correctly in a timely
>> fashion?


Preston Briggs writes:
> Many people say "absolutely not", mainly because of the correctness
> requirement. I guess there are a lot of examples that suggest it's hard.
> Is it harder than other interesting software? I'm not sure.


CORRECTLY-
How to build reliable compilers:
1) Hire people who can demonstrate they know as much about modern software
      engineering practices as they do about the application area (compilers).
      Hire people who have a systematically perverted way of writing code
      to be your test case developers. Too many places put their drones into
      test work.


2) Consistently follow the best software engineering practices you can
      afford to adopt. For example, software redundancy is worth it when
      build space shuttles autopilots, maybe not when building compilers.
      We like the object-oriented approach. We also use huge amounts of
      cycles for testing, which is easier if you are a system manufacturer.


3) Invest lots of money buying or building a sophisticated software
      development environment. Not syntax-directed-editors and other fluff,
      but components you can re-use and tools to help you test, debug, and
      build your code. 'sophisticated optimizing compilers' are large
      software systems, with many hundreds of thousands of lines of code.
      Such systems require a significant infrastructure.


5) Collect at least a million lines of real application code to run
      through your compiler, in addition to the tests you write.


I claim that the level of compiler reliability is a function of the log10
of the number of application source lines that have been successfully
compiled and executed. There isn't much difference between a compiler
that has mastered 10K lines and 20K lines, but there does seem to be a
difference between mastering 10K lines and 100K lines, or 100K lines and
1,000K lines. Not many compilers have made it to the 10,000K line
reliability stage.


> The definition of "timely" is also important here. There are recent
> interesting compilers from IBM and Convex. How "timely" were they?
> I expect Convex has spent far less developing their compiler system (how
> could they possibly outspend IBM?). Was it developed in a "timely"
> fashion? I don't think we (outside of Convex) can really tell. It's a
> new (or enhanced) compiler for an existing machine.


TIMELY-


I assume you're talking about the CONVEX Application Compiler, Preston.
We had the good fortune to be building from a sound basis - the procedure
compiler components had evolved over half a decade and a great deal of
effort had been put into making them reliable. On the other hand, I can
say that the hardest bugs we had to correct during development were in the
procedure compiler component - code making assumptions that were no longer
true now that interprocedural information was available.


I spent the first half of my career developing applications, not
compilers. I don't find budgeting, planning, or managing 'sophisticated
optimizing compilers' development all that much more difficult than doing
the same for applications. I think the much-ballyhooed delays in PC
application software (Lotus, etc) indicate that timeliness is a software
engineering problem, not a problem unique to compilers. One advantage you
have with compilers is that the user isn't constantly changing the
requirements, although performance surprises when the hardware is actually
delivered have the same sort of impact.


Many software engineering people point out that a schedule must comprehend
which parts of your project 'go where no man has gone before'. You must
double whatever estimates you make for these, because as Fred Brooks said
in the Mythical Man-Month: 'Plan to throw one away'.


Our estimates for those parts of the Application Compiler which had been
implemented in some research center before us were quite good. The
estimates for the work required for the parts where previous research was
thin or non-existent should have assumed that we would throw the first
implementation away, because we were in effect doing research. We did
major rewrites in each of these areas, and in effect doubled the estimated
time.


Overall, our schedule and budget were within expectations. In the real
world, there is a third parameter (functionality). You can cut it if the
other two parameters are fixed, and something takes longer than you
thought it would.


/Bob Metzger
--

Return to the comp.compilers page.
Search the comp.compilers archives again.