Newsgroups: comp.lang.fortran
Path: utzoo!utgpu!news-server.csri.toronto.edu!helios.physics.utoronto.ca!alchemy.chem.utoronto.ca!system
From: system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson))
Subject: Re: why does optimization take so long ?
Message-ID: <1991May21.182127.4097@alchemy.chem.utoronto.ca>
Organization: University of Toronto Chemistry Department
References: <1236@nikhefh.nikhef.nl> <KHB.91May20200715@chiba.Eng.Sun.COM>
Date: Tue, 21 May 1991 18:21:27 GMT

In article <KHB.91May20200715@chiba.Eng.Sun.COM> khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) writes:
>
>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...	
>
> ...
>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 probably tell the symbolic manipulator to do this - Maple
certainly will. It then produces much more intelligible code, both for
humans and compilers.

>You can rightly critize the compilers behavior, but you probably are
>more concerned with improving performance than tossing brickbats ;>

I sent in 2 examples of this sort of code, and Apollo's response was
"will not be fixed". They didn't agree that the compiler spending over
12 hours of cpu time (and still not producing an object file) on a
program was worthy of correction - I did not ask for the compiler to
compile the code, just to give a message that the code exceeds its
capabilities (and a message to tell the user to simplify the program 
would be an added bonus :-).

Mike.
-- 
Mike Peterson, System Administrator, U/Toronto Department of Chemistry
E-mail: system@alchemy.chem.utoronto.ca
Tel: (416) 978-7094                  Fax: (416) 978-8775
