Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!sun-barr!newstop!sun!chiba!khb From: khb@chiba.Sun.COM (chiba) Newsgroups: comp.sys.apollo Subject: Re: PRISM Fortran compiler causes trashing! Message-ID: <129179@sun.Eng.Sun.COM> Date: 13 Dec 89 09:53:07 GMT References: Sender: news@sun.Eng.Sun.COM Reply-To: khb@sun.UUCP (chiba) Organization: Sun Microsystems, Mountain View Lines: 34 In article hanche@imf.unit.no (Harald Hanche-Olsen) writes: >This is a short tale about a long FORTRAN compilation on the DN10000. >... >Rhetoric question: What do those compiler writers at HP/apollo think >they're doing? Writing for machines with a minimum of 128M of memory? > Most (all I have ever seen, from PDP-11 to Cray) unix compilers act this way. In the unix universe the common idiom is to store things which are different in different files. This permits make to act in a sensible fashion. In addition, it is seldom a good idea to compile a large application with the optimizer set to just one setting for the whole application on machines with interesting optimizers. The proper approach is to compile at low (or no) levels of optimization, and to enable profiling. Optimizers can, and will be serious pessimizers in some cases (consider a machine with multiple functional units and long pipes, and an application which has loops which run from 1 to 3 ... but this is hidden from the compiler .... all loops will be unrolled to a depth of beyond 3 ... and etc.). In addition, most often the modules most expensive to optimize are the ones with the least payoff... Lastly, one should consider one of Amdahl's old "laws" .... 1MIP => 1Mb of RAM. Keith H. Bierman |*My thoughts are my own. !! kbierman@sun.com It's Not My Fault | MTS --Only my work belongs to Sun* I Voted for Bill & | Advanced Languages/Floating Point Group Opus | "When the going gets Weird .. the Weird turn PRO"