Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!sdd.hp.com!cs.utexas.edu!sun-barr!newstop!exodus!exodus-bb!khb From: khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) Newsgroups: comp.lang.fortran Subject: Re: why does optimization take so long ? Message-ID: Date: 21 May 91 03:07:15 GMT References: <1236@nikhefh.nikhef.nl> Sender: news@exodus.Eng.Sun.COM Organization: Sun MegaSystems Lines: 32 In-reply-to: t19@nikhefh.nikhef.nl's message of 20 May 91 19:58:03 GMT In article <1236@nikhefh.nikhef.nl> t19@nikhefh.nikhef.nl (Geert J v Oldenborgh) writes: qqgg= n1i*n2i*pbqi*ptqi * ( - 2*pnpe*pbpt**2*qk + 2*pnpe* + qk*mb2*mt2 + 2*pnpb*pepb*pbpt*qk - 2*pnpb*pepb*qk*mt2 + 2* + pnpb*pept*pbpt*qk + 4*pnpb*pept*pbpt**2 - pnpb*pept*qk*mb2 - ...400 similar lines... presumably all 400 lines are in a single basic block. The majority of modern compilers tend towards being a bit naive and try to do vast amounts of analysis on basic blocks (and often perform transformations to make bigger ones). However, a basic block can be "too big" and a clever enough compiler would essentially break it into several loops (each of which would maximially utilize the register set(s)). You may very well see improvement both in compile speed and execution speed if you break up the computation into several smaller loops. You can rightly critize the compilers behavior, but you probably are more concerned with improving performance than tossing brickbats ;> Sun's f77 v1.4 does a bit better on problems of this sort, but we aren't out of the wood yet. (btw: adding tons of RAM is also helpful). -- ---------------------------------------------------------------- Keith H. Bierman keith.bierman@Sun.COM| khb@chiba.Eng.Sun.COM SMI 2550 Garcia 12-33 | (415 336 2648) Mountain View, CA 94043