Newsgroups: | comp.compilers |
From: | henry@zoo.toronto.edu (Henry Spencer) |
Organization: | U of Toronto Zoology |
Date: | Sun, 13 Dec 1992 05:09:24 GMT |
Keywords: | optimize |
References: | 92-12-029 92-12-049 |
> 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:
>... any programmer who is making a serious effort to write high-
>performance code must know approximately how often each of the conditional
>branches in critical sections is taken...
I agree with this statement, with one crucial substitution: for "must"
read "should", in the sense of "you should stay below the speed limit".
When people first started implementing profilers and the like, they found
one striking result: human intuition about the locations of the hot spots
in a complex program was *consistently wrong*. All kinds of attention had
gone into optimizing things that weren't important, or even made things
worse in unforeseen ways.
>... It's a question of understanding what the code is doing: an
>understanding which is fundamental to optimization.
Indeed so. And you get that sort of understanding only by measurement.
Guesswork, even informed guesswork, is known to be inadequate... but
people rely on it nevertheless.
If you've got the measurements, just supplying *them* direct to the
compiler works much better. If nothing else, it avoids the temptation to
skip that annoying measurement step and just wing it.
--
Henry Spencer @ U of Toronto Zoology, henry@zoo.toronto.edu utzoo!henry
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.