Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!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: <129180@sun.Eng.Sun.COM> Date: 13 Dec 89 10:02:34 GMT References: <47625cb9.20b6d@apollo.HP.COM> Sender: news@sun.Eng.Sun.COM Reply-To: khb@sun.UUCP (chiba) Organization: Sun Microsystems, Mountain View Lines: 32 In article <47625cb9.20b6d@apollo.HP.COM> madler@apollo.HP.COM (Michael Adler) writes: >You are quite correct that 8MB isn't much for compiling large programs. >However, I strongly discourage breaking apart source files for users with >reasonable amounts of memory. ... I have not used the PRISM compiler, but have used many others with similar behavior. Really large programs should typically be broken, profiled and if necessary reassembled. On one large commerical FE code (276K lines), for a largish computer (names withheld) the moral equivalent of saxpy was called several hundred times. Inlining (which would have been natural) all such call sites was a big lose. In about 4 call sites, inlining, loop interchanges, hand unrolling to a depth of 3 (all calls were multiples of 3) and some other vile and unnatural transformations resulted in a total application speedup of more than a factor of 2. >Breaking routines apart into separate source files causes longer calling >sequences, makes inlining (-opt 4) impossible and destroys any chances for >interprocedural optimizations. Compilers can only do so much. In addition, the cost of compilation dominates in many shops .... 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"