Newsgroups: | comp.compilers |
From: | chased@rbbb.Eng.Sun.COM (David Chase) |
Organization: | SunPro |
Date: | Sat, 12 Dec 1992 20:15:16 GMT |
Keywords: | optimize |
References: | 92-12-029 92-12-049 |
Henry Spencer <henry@zoo.toronto.edu> writes:
> The other problem that occurs with such facilities is that programmer
> intuition is notoriously unreliable about such things.
idacrd!desj@uunet.UU.NET (David desJardins) writes:
>I don't understand this statement in this context in this context. I know
>it's fashionable in this group to claim that compilers are supergeniuses
>and humans are idiots.
Compilers are super-patient and humans are not.
>But any programmer who is making a serious effort to write high-
>performance code must know ...
You've got to be careful about confusing common-case and best-case. If
80% of the programmers either don't bother or don't know 80% of the time,
then I'd call that "notoriously unreliable". That still leaves plenty of
room for many people to occasionally know exactly what is happening.
However, those people are a distinct minority, and catering to their needs
is not likely to bring as large a reward as catering to the needs of the
common case. (I.e., consider economics.)
>Of course, I too endorse the feedback of profiler information as a more
>convenient (to the user) way to achieve similar results.
Because it is more convenient, it is used by more people, and hence has a
bigger reward than special-case frequency hints. Profiling feedback is
also useful because it does not require source code changes -- if you
discover that your training inputs are not typical, you merely get some
better ones, train, and recompile. Source code changes are much more
costly because they involve more human interaction and can include the
possibility of introducing errors (even if only a typo).
David Chase
Sun
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.