[comp.lang.fortran] f8x impact on debugging

dph@lanl.gov (David Huelsbeck) (04/18/89)

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

khb@chiba.Sun.COM (chiba) (04/18/89)

In article <12179@lanl.gov> dph@lanl.gov (David Huelsbeck) writes:
>
>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.

Some of the old hacks cause current optimizing compilers grief. If one
has lots of equivalences, it may be hard to do certain types of code
motion and loop transformations...due to the increased complexity of
data dependency analysis.

Cheers.

Keith H. Bierman          *My thoughts are my own. Only my work belongs to Sun*
It's Not My Fault          
    ---- I Voted for Bill & Opus

jlg@lanl.gov (Jim Giles) (04/21/89)

From article <44400038@hcx2>, by bill@hcx2.SSD.HARRIS.COM:
> 
> To answer Jim Giles question: "Are there features that impact efficiency
> even if not used?"

Actually, I didn't ask that question (I'll have to check back for who
did).  But, thanks for your answer anyway.

It has been my experience, though, that adding new features doesn't prevent
vendors from improving the Fortran compiler in other ways - it prevents
them from spending time implementing other languages.  A host of new Fortran
features may actually cause the quality of commercial compilers to improve
since the vendors will be forced to work on them again.

cdb@hpclcdb.HP.COM (Carl Burch) (04/22/89)

> I do not know what will happen on scalar machines.  For example, I have
> heard it rumoured that DEC opposes the array notation because the need
> to pass an array descriptor (rather than just a pointer to the start of
> the array) forces one more level of indirection in array references,
> and that this is a bad thing on a VAX.  Although I would guess that
> this potential trouble could be optimized away, it is this sort of
> information is what is needed to judge the efficiency issues.

     The rules for when (in effect) dope vectors will have to be passed
have been very carefully designed so that even nonoptimizing compilers
need not pass dope vectors for any FORTRAN 77 code.  Dope vectors will only
be required to be available when the "interface is explicit" - i.e., when 
the callee is the subject of an interface block or is USEd from a module, 
both F8x features - and only are necessary in some cases (e.g., assumed-
shape dummy argument arrays).
							- Carl Burch

bill@hcx2.SSD.HARRIS.COM (04/25/89)

> Actually, I didn't ask that question (I'll have to check back for who
> did).  But, thanks for your answer anyway.

Oops, sorry.

> It has been my experience, though, that adding new features doesn't prevent
> vendors from improving the Fortran compiler in other ways - it prevents
> them from spending time implementing other languages.  

What other languages?  :-) I don't know about your vendor, but we don't
implement a new language every day.  We're too busy keeping up with the
ones we have!

> A host of new Fortran features may actually cause the quality of
> commercial compilers to improve since the vendors will be forced to work
> on them again.

Don't you believe it!  Nothing could be further from the truth.  If their
existing FORTRAN compiler was designed with 8x in mind, then it probably
hasn't "matured" yet (it can't be too old, can it?); that is, it probably
still doesn't generate "wonderful" code, and may still be a bit unstable.
(In my experience, it takes about 3 years after the first release of a
compiler for it to become reasonably stable.)  In that case, the code
improvement and bug-fix rate is likely to slow considerably while all
those new features are put in.  In fact, I dare say the stability will
decline considerably, as those new features interact with the old ones
in exciting ways.  :-)

If their existing FORTRAN compiler was NOT designed with 8x in mind, then
adding those "host of new features" is likely to destabilize the compiler,
possibly forever.  If one were to consider all the costs involved, it
probably is not economically viable to add those features to a mature and
stable compiler.  You would be better off doing another one (perhaps
reusing some code from the old one), rather than making your existing
customers mad, losing benchmarking contests because the compiler aborts
(yes, it happens), etc.

Your comment suggests that the vendor isn't working on the compiler.  There
is probably a very good reason: if it ain't broke, don't fix it.
Compilers, like other large programs, eventually mature to a point where
any change breaks more than it fixes; the prudent vendor recognizes this
and stops making changes.

Bill Leonard
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
bill@ssd.harris.com or hcx1!bill@uunet.uu.net

jlg@lanl.gov (Jim Giles) (04/26/89)

From article <44400039@hcx2>, by bill@hcx2.SSD.HARRIS.COM:
>> It has been my experience, though, that adding new features doesn't prevent
>> vendors from improving the Fortran compiler in other ways - it prevents
>> them from spending time implementing other languages.  
> 
> What other languages?  :-) I don't know about your vendor, but we don't
> implement a new language every day.  We're too busy keeping up with the
> ones we have!

Well, Cray has been spending _a_lot_ of time and resources on C and Pascal
lately.  The only change in Fortran has been to rewrite the compiler in
Pascal - it now runs _MUCH_ slower and produces code that is about the
same or (perhaps) _marginally_ faster.  I'm sure they could have done
better on the new Fortran if they hadn't wasted so much on C et. al..



.

mccalpin@loligo.cc.fsu.edu (John McCalpin) (04/26/89)

In an earlier article, I wrote that I don't expect Fortran-8X to
adversely effect the efficiency of my codes.

In article <12170@lanl.gov>, by jlg@lanl.gov (Jim Giles) Jim replies
that efficiency is a "major problem" with his applications, and
continues: `... This seems to represent the difference between
university computer attitudes and those of the "real world"....'

In article <12179@lanl.gov> dph@lanl.gov (David Huelsbeck) writes:

>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.

Yes. In fact, the array notation from 8X should make it much easier for
the compiler to figure out how to run my code efficiently on a vector
machine. 

It is amazing the contortions that programmers are willing to go
through to get vectorizers to understand their codes.  It is equally
amazing the effort that vendors go through to write vectorizers to
infer vector operations from (syntactically) scalar code.  But what is
most amazing is that so few people think that this is an odd approach!

I have suspected that the reason that vector coprocessors are so scarce
on small machines (e.g. Sun's) is that so few companies have the
resources to build a decent vectorizer.  Now perhaps some companies
will be in a better position to produce such things --- the restriction
would be that only explicit vector code would run on the coprocessor.

>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.

Deprecation is not *gone* from the draft, but no features are currently
included in that list.

>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.

This is the big issue that needs to be addressed here.  I think that the
new draft looks great.  I hear lots of talk that the compilers will not
be able to produce good code, but I have not yet heard any *specific*
arguments.

>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).

And there is nothing (except money?) stopping vendors from using an
intermediate code to allow interprocedural optimization (a la MIPS).

>-dph
-- 
----------------------   John D. McCalpin   ------------------------
Dept of Oceanography & Supercomputer Computations Research Institute
mccalpin@masig1.ocean.fsu.edu		mccalpin@nu.cs.fsu.edu
--------------------------------------------------------------------