Re: Death by error checks.

Veeru Mehta <veeru@hpclearf.cup.hp.com>
17 Dec 1995 00:21:21 -0500

          From comp.compilers

Related articles
[3 earlier articles]
Death by error checks. dave@occl-cam.demon.co.uk (Dave Lloyd) (1995-11-27)
Re: Death by error checks. jgj@ssd.hcsc.com (1995-11-28)
Re: Death by error checks. sethml@dice.ugcs.caltech.edu (1995-11-28)
Re: Death by error checks. Terry_Madsen@mindlink.bc.ca (1995-11-30)
Re: Death by error checks. cliffc@ami.sps.mot.com (1995-11-30)
Re: Death by error checks. sethml@avarice.ugcs.caltech.edu (1995-12-09)
Re: Death by error checks. veeru@hpclearf.cup.hp.com (Veeru Mehta) (1995-12-17)
Re: Death by error checks. hbaker@netcom.com (1995-12-19)
| List of all articles for this month |
From: Veeru Mehta <veeru@hpclearf.cup.hp.com>
Newsgroups: comp.compilers
Date: 17 Dec 1995 00:21:21 -0500
Organization: Compilers Central
References: 95-10-103 95-11-192
Keywords: syntax, design

Terry Madsen <Terry_Madsen@mindlink.bc.ca> wrote:
>sethml@dice.ugcs.caltech.edu (Seth M. LaForge) writes:
>> [ Profile-based optimization ]
>
>Most importantly, regardless of the environment, I fail to see why being
>able to profile code and feed the results back to a second compile is a
>"better" way to tell the compiler something that the programmer knows in
>the first place. This has been a bit of a peeve of mine: the claim that
>profilers know which branches are taken better than the programmers who
>wrote the code. Even if this is the case for "algorithmic" branches,
>profiling makes for a clumsy way to build a large product, and leaves the
>error-checking branches no better than if they'd been explicitly specified
>in the source.


I believe the goal of compiler writers should be to help the
programmer rid of low level optimization details. One of the main
advantages of a higher level programming language is that you get rid
of the housekeeping jobs you had to do with a lower level
language. This extends to any optimizations which can be taken care of
in a mechanical way. Ideally the programmer should concentrate
primarily on algorithmic improvements, but we see a lot of time
consumed on improving an itsy bitsy hot-spot code; something that a
profiler+compiler could do in a better way. In any case, to be
completely sure, a programmer has to run a profiler anyway.


So where is the problem in having an arrangement that does the same
thing ? Some programmers may want to predict the branches on their
own, but a vast majority would simply want to concentrate on the
algorithmic issues. This also helps the generated program to be closer
to the algorithm than otherwise (A rather bad analogy here would be
the differences between a yacc conforming grammar and the original
one). I think it's time a lot of compiler writers got 'down' to the
'common' programmer level and try to ease their burden in whatever way
they can.


Veeru.
--


Post a followup to this message

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