Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!ames!haven!adm!cmcl2!lanl!dph
From: dph@lanl.gov (David Huelsbeck)
Newsgroups: comp.lang.fortran
Subject: f8x impact on debugging (was: Re: yes vs. no on f8x)
Message-ID: <12179@lanl.gov>
Date: 17 Apr 89 20:05:59 GMT
References: <12170@lanl.gov>
Organization: Los Alamos National Laboratory
Lines: 37

From article <12170@lanl.gov>, by jlg@lanl.gov (Jim Giles):
> From article <590@loligo.cc.fsu.edu>, by mccalpin@loligo.cc.fsu.edu (John McCalpin):
>> This seems to me to be a substantive issue.  I happen to work in
>> vector-supercomputer-land, where efficiency is not a problem.  My codes
>> will simply change from several thousands of lines of sequential DO loops
>> to a few thousand lines of array notation.
> 
> I happen to work in vector-supercomputer-land - and efficiency is _the_
> major problem.  This seems to represent the difference between university
> computer attitudes and those of the "real world".


Hmmm. So this is the "real world" huh?

I think what John was trying to say was that in his estimation the 8x 
changes would not impact his efficiency adversely because they
wouldn't change the way he writes code other than to make some constructs
much less verbose.  I'm sure John will correct me if I'm wrong.

Since deprecation etc. is now gone from the draft any of the old hacks
that improved efficiency should still work.  Further more, no one is
implying that they're going to be taken away any time soon.  Are there
any additions that should impact the efficiency of codes that don't use
them?  I have a copy of the draft but I don't know as much about 
optimization and vectorization as Jim and Co.

Why should people be upset if features that are inefficient only when
used are added?  Separate compilation limits optimization but I haven't
heard anybody asking to have it removed (for that reason).

On to the real subject of this posting.  How will 8x impact source level
debugging of optimized code?  I'm not familiar enough with this issue to
say but it seems like condensing multi-line nested DO constructs into
single statements in array notation would be a plus for debugging
optimized code.  Any opinions?

-dph