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