Path: utzoo!attcan!uunet!steinmetz!davidsen From: davidsen@steinmetz.ge.com (William E. Davidsen Jr) Newsgroups: comp.arch Subject: Re: Professional Programmers (was: Seeing the future) Message-ID: <12688@steinmetz.ge.com> Date: 29 Nov 88 14:56:04 GMT References: <1984@eos.UUCP> <28200245@mcdurb> <321@taux02.UUCP> Reply-To: davidsen@crdos1.UUCP (bill davidsen) Organization: General Electric CRD, Schenectady, NY Lines: 25 In article <321@taux02.UUCP> amos@taux02.UUCP (Amos Shapir) writes: | Having seen some programs written by scientists, I am not at all amazed. | Most of what a professional programmer does when helping scientists, | is to change things like cos(atan(x))**2 to 1/(1+x*x) . You mean your optimizing compiler doesn't even do THAT??? In many cases a compiler will do a better job of handling global optimization, code movement, and common subexpressions than a human. Humans excel in recognizing special cases in a small section of code (at least the good ones do). I have seen The VMS C compiler push a value about 100 instructions before it was popped, and avoid a division. A human would probably never find that code, if only because the flow analysis is very tedious to insure that the value is always popped. I have seen output from research projects which recognize sequences of code in separate procedures and generate internal calls to the common code from several places, with values in registers. Obviously this is a savings in space rather than time (calls take time) but it is impressive in terms of recognizing program patterns. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me