Re: Death by error checks.

sethml@dice.ugcs.caltech.edu (Seth M. LaForge) writes:


> On Tue, 21 Nov 1995 13:51:03 GMT, Ian Ringrose <ianr@lsl.co.uk> wrote:
>
>+ What I would like to do, is give the 'c' compiler a hint in the macro,
>+ that the 'if' should be predicted not taken. Are there any 'c'
>+ compilers that let me give the hint. (We build on Unix systems from Sun,
>+ Dec, IBM, and HP.)
>
> I don't know of any compilers to which you can explicitly give such a
> hint, but HP's compiler will something better: profile-based
> optimization. Just compiler your program with the appropriate profiling
> turned on and run it for a while. It dumps into a file information about
> how often each branch is taken/not taken. You then feed this file to the
> compiler when recompiling your program, and it uses the profile
> information to optimize branches.


Unfortunately there are many compilers which do not do this. M$ products
on x86 DOS/Windows, for example, and Mr Ringrose's, from the sound of his
posting. Anyway, for data-processing code of the "2 megabytes and no
loops" sort, this is at best a very time-consuming process: build one
night, run all the profiling seed code, then build it again. This is
assuming that the seed code can adequately exercise all the code of
interest enough times to make the profiler (if it exists) notice something
it considers significant.


Here's another problem: what if late in a project, a program change causes
the usage pattern to change, and a DLL to change, that you didn't touch at
the source level? Many places don't test source code, they test and
*approve* object (executable) code: a changed object is an untested one.
Putting object code optimization out of the programmer's reach, with the
risk of something changing two days before ship, won't fly; given the
choice between profiling-based optimization and none at all, I'd choose the
latter for this reason alone.


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. For a lot of "real-world" applications (at least the
consumer market ones), specifying which way the code is expected to go
could be good enough to eliminate the need (if not the desire) to do
profile optimizing at all.


Since many compilers already claim to have internal heuristics to decide
whether a branch should be compiled as faster-taken or faster-not-taken (on
machines where it makes a difference), it seems as if a user directive
could be made an additional (overriding) parameter to this decision
process. For reasons such as the product-control issue noted above, it may
be at least as useful to specify "optimize it for this condition" as to
specify a trace and allow automatic optimization.


terry
--

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