From: | sberg@camtronics.com (Scott A. Berg) |
Newsgroups: | comp.arch,comp.compilers |
Date: | 31 Mar 1996 17:20:25 -0500 |
Organization: | Alpha.net -- Milwaukee, WI |
References: | 96-03-006 96-03-110 96-03-139 |
Keywords: | optimize |
> in other words, even the programmer that wants his code to go fast
> should concentrate on the readability of his code more than on using
> tricks like '+='.
cliffc@ami.sps.mot.com says...
>Yes. Readable code is much easier to do performance analysis on,
>which can lead to algorithmic changes for big-O speedups (to say
>nothing of what the programmer that follows you thinks of your code).
Well in general I agree, but no one seems to have covered the all too
common dead end. Suppose you want to sort a list of a few hundred
seemingly random integers (no special properties to exploit like being
generated in almost sorted order) and you are already using quicksort
(or some other O(n log n) algorithm) and it's still too slow. There
ARE no faster algorithms and diddling with the code to squeeze a few
constants can make the difference.
Besides, I've rarely run into the need for such a distinct function as
a list sort or a string search or some other "classroom example"
algorithm, and deriving minimal big-oh algorithms is rarely a pastime
in industry.
Bottom line:
1) There will always be a need for assembly language bit-jocks, but
both the demand and the supply pool will get smaller.
2) There will always be a need for board layout experts, no matter how
many auto-routers are on the market.
3) There will always be a need for a good auto mechanic, no matter how
electronic the ignition gets.
4) And so on. Perhaps creating this list would be another good thread!
--
Scott A. Berg
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.