dd@beta.lanl.gov (Dan Davison) (04/12/89)
Of course someone can present the negative side of F8X to an audience and get them to be negative, and similarly for the positive side. Neither is relevant, really. I think I could do an adequate job either way. What's really needed is a short pro vs. con document, perhaps by x3j3 committee members. Distributed by network and by interested organizations it would be more useful than watching competing claims go by on the net. It would probably reach more people, too. A properly done document would help to create that "informed opinion" that Keith Bierman wants (*). dan davison/theoretical biology/t-10 ms k710/los alamos national laboratory los alamos, nm 875545/dd@lanl.gov (arpa)/dd@lanl.uucp(new)/..cmcl2!lanl!dd (*) but if that opinion disagrees with him, I get the impression that it would still be "uninformed". At least that's the way his postings read to me...
khb@fatcity.Sun.COM (Keith Bierman Sun Tactical Engineering) (04/13/89)
In article <24130@beta.lanl.gov> dd@beta.lanl.gov (Dan Davison) writes: >(*) but if that opinion disagrees with him, I get the impression that >it would still be "uninformed". At least that's the way his >postings read to me... Au contrai (sp). Alex Marzuk and Igor Phillips are both anit-draft and very well informed. I appreciate their positions, and respect their depth of understanding. Nor should it be infered that they are the only folks who are informed and still against the proposed standard. What is irksome is that I still find people who completely in the dark, but firmly against the proposal. If I have given the impression that all who are against me are misinformed neo-luddites, I apologise to those of you who are neither. cheers Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus
alm@a.lanl.gov (Alex Marusak) (04/14/89)
In article <98678@sun.Eng.Sun.COM>, khb@fatcity.Sun.COM (Keith Bierman Sun Tactical Engineering) writes: > > Au contrai (sp). Alex Marzuk and Igor Phillips are both anit-draft and > very well informed. I appreciate their positions, and respect their > depth of understanding. Alex L. Marusak and Ivor R. Philips (in absentia) thank you. I respect your opinions as well. > > Nor should it be infered that they are the only folks who are > informed and still against the proposed standard. What is irksome is > that I still find people who completely in the dark, but firmly > against the proposal. This is the crux of X3J3's problem. I think you have profoundly misunderstood the public review comments. The scientists and engineers are not saying that they lack the brainpower to learn Fortran 8x. They are saying that they don't WANT to. They believe that Fortran should be a powerful tool to be used and appreciated, not a hurdle to be overcome. When I joined X3J3 in the early '80s, I had the following rule of thumb: I would read a proposal, and if I didn't understand it I would read it again. If I still didn't understand it, I would vote 'no'. I still have this rule of thumb, but unfortunately I'm now too familiar with the writing styles of X3J3. On a clear day and with a running start, I can read the most turgid of prose and make sense of it (sort of like this note I'm generating). I am so used to going right to the fine points that I tend to forget how awful it really is. I (re)read the current draft from cover to cover, and I thoroughly enjoyed the experience. I also like to do the Sunday crossword puzzle in ink. Mr. Bierman, the public is telling you and me that they have other important things to do. Regards, Alex Marusak
mccalpin@loligo.cc.fsu.edu (John McCalpin) (04/14/89)
In article <867@a.lanl.gov> alm@a.lanl.gov (Alex Marusak) writes: > >This is the crux of X3J3's problem. I think you have profoundly >misunderstood the public review comments. The scientists and >engineers are not saying that they lack the brainpower to learn >Fortran 8x. They are saying that they don't WANT to. This makes no noticeable sense at all as an objection to the current draft. If "scientists and engineeers" do not want to learn any of the new features in the language, then they certainly don't have to. I am quite certain that people will continue to write in FORTRAN-77 for a decade after the new compilers are out, since we have people who still write FORTRAN-66 even now in 1989.... If the "scientists and engineers" do not want anyone else to be able to use the new features (perhaps out of fear that one day they might have to use someone else's code), then we might as well quit doing science, too. We might accidently learn something that they don't understand, and would have to learn about.... >They believe >that Fortran should be a powerful tool to be used and appreciated, >not a hurdle to be overcome. I certainly agree. It is about time for Fortran to be made into a "powerful tool". This requires most of the changes (like modules, user-defined types, & operator overloading) that you claim that the "scientists and engineers" oppose. The new power of the current draft language certainly allows fo abuse (witness the bizarre example of the package to do arithmetic on Roman numerals in the Argonne report on F8X), but programs that are carefully written using modularity, data structures, and operator overloading are MUCH easier to read and maintain than their FORTRAN-77 equivalents. >When I joined X3J3 in the early '80s, I had the following rule of >thumb: I would read a proposal, and if I didn't understand it I >would read it again. If I still didn't understand it, I would vote >'no'. The writing style of the proposal has nothing to do with the value of the language. I certainly found the previous draft to be mysterious in parts (and inconsistent in others), but I also do not expect to use the standard as a textbook. >Mr. Bierman, the public is telling you and me that they have other >important things to do. Some of us are telling you (X3J3) that we have work to do, and we are tired of putting up with the archaic language of Fortran. The new draft (or something much like it) offers the only realistic chance for a widespread (i.e. portable) language to exist that provides both abstraction and performance for scientific and engineering applications. I, for one, am very anxious to get this standardization process over with so that the manufacturers can do their implementations and I can get on with my work. >Regards, >Alex Marusak -- ---------------------- John D. McCalpin ------------------------ Dept of Oceanography & Supercomputer Computations Research Institute mccalpin@masig1.ocean.fsu.edu mccalpin@nu.cs.fsu.edu --------------------------------------------------------------------
alm@a.lanl.gov (Alex Marusak) (04/15/89)
In article <584@loligo.cc.fsu.edu>, mccalpin@loligo.cc.fsu.edu (John McCalpin) writes: % . . . % The new power of the current draft language certainly allows % fo abuse (witness the bizarre example of the package to do % arithmetic on Roman numerals in the Argonne report on F8X), % but programs that are carefully written using modularity, % data structures, and operator overloading are MUCH easier % to read and maintain than their FORTRAN-77 equivalents. % . . . % The writing style of the proposal has nothing to do with % the value of the language. I certainly found the previous % draft to be mysterious in parts (and inconsistent in others), % but I also do not expect to use the standard as a textbook. % . . . % Some of us are telling you (X3J3) that we have work to do, and % we are tired of putting up with the archaic language of % Fortran. The new draft (or something much like it) offers the % only realistic chance for a widespread (i.e. portable) language % to exist that provides both abstraction and performance for % scientific and engineering applications. % . . . It seems to me that you have considered carefully the complexity issue, have measured it against the added power that Fortran 8x would give you, and have come down strongly in the "yes" column on "shall we have Fortran 8x?" At our laboratory (in percentages roughly comparable to all the U.S. public comments), about 25% of the commentators agreed with your view, about 25% were indefinite, and about 50% disagreed. % In article <867@a.lanl.gov> alm@a.lanl.gov (Alex Marusak) writes: % > % >This is the crux of X3J3's problem. I think you have profoundly % >misunderstood the public review comments. The scientists and % >engineers are not saying that they lack the brainpower to learn % >Fortran 8x. They are saying that they don't WANT to. % . . . % If the "scientists and engineers" do not want anyone else to be % able to use the new features (perhaps out of fear that one day % they might have to use someone else's code), then we might as % well quit doing science, too. We might accidently learn % something that they don't understand, and would have to learn % about.... Your response (in which you equate 'a desire for simplicity' with 'a fear of the unknown') convinces me more than ever that the misunderstanding is profound. It does NOT mean you're wrong. It does NOT mean you're right. It means that X3J3 has a big, big problem.
mccalpin@loligo.cc.fsu.edu (John McCalpin) (04/15/89)
In article <584@loligo.cc.fsu.edu>, I wrote stuff indicating my approval of the new draft Fortran standard. In article <877@a.lanl.gov> alm@a.lanl.gov (Alex Marusak) replied: >It seems to me that you have considered carefully the complexity >issue, have measured it against the added power that Fortran 8x would >give you, and have come down strongly in the "yes" column on "shall we >have Fortran 8x?" I was a bit confused by Marusak's first posting, in which he implied that the new complexity of the language *in itself* was a negative factor. As I pointed out, FORTRAN-77 codes will be completely supported, so this is a moot point, and one I have not heard before from informed commentators. The objection that I *have* heard repeatedly is more like: Complexity is only a problem because it will destroy the efficiency of Fortran compilers/optimizers, and Fortran is the only language that we have that is both portable and efficient. (Apologies to C) 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 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. It is precisely this hard information on what the new standard will require compilers to do that is missing in this newsgroups discussions. Are there any compiler writers out there that want to enlighten us? >It does NOT mean you're wrong. It does NOT mean you're right. >It means that X3J3 has a big, big problem. Yup. -- ---------------------- John D. McCalpin ------------------------ Dept of Oceanography & Supercomputer Computations Research Institute mccalpin@masig1.ocean.fsu.edu mccalpin@nu.cs.fsu.edu --------------------------------------------------------------------
bill@hcx2.SSD.HARRIS.COM (04/18/89)
> It is precisely this hard information on what the new standard will > require compilers to do that is missing in this newsgroups discussions. > Are there any compiler writers out there that want to enlighten us? I would love to. I have been trying to do so for the past year. Either I have failed miserably, or you haven't been reading this newsgroup that long. :-) Unfortunately, most of my attempts to "enlighten" people about what FORTRAN/8x will do to compilers has been "misinterpreted", perhaps partly because I work for a (dare I say it?), a VENDOR! And, as everyone knows, vendors are always against progress and innovation and children and Mom and apple pie and patriotism and anything else that's good and decent. Anyway, I think your example of the array notation is an excellent place to start. Probably, users of supercomputers and minisupercomputers will see very little difference between using the array notation or using DO loops. Perhaps their compiles will go faster, as the compiler has less work to do, but they probably already go so fast as to appear instantaneous. However, users of scalar machines, particularly small scalar machines, will see a HUGE difference. Their compiles will probably go much slower, or their code will execute much slower, or both. Now, before we go any further, I have made an assumption: that both sets of users are dealing with code that has been hand-optimized as much as possible, that the best algorithms have been used, etc., and then those algorithms converted from DO loops to the 8x array notation. First, let's consider a relatively simple compiler, the kind you would probably find on a PC or small workstation. That compiler will probably transform each array statement into one, possibly two, loops. (I say two because the 8x rules say that, in effect, the entire right-hand side of the assignment is evaluated prior to altering the left-hand side. Only in very simple cases can a compiler trivially detect that this can be avoided without harm; the other cases require more analysis than our example compiler would typically want to do, given the horsepower and memory available.) Now if your original DO loop was only doing that one statement, then you have lost nothing (yet). But, judging from code I have seen from customers, that is seldom true -- users typically put multiple, independent operations in one DO loop to save on the loop overhead. In that case, you have traded one loop for n loops. Furthermore, any temporary arrays required to evaluate the right-hand side of the assignment will probably be allocated dynamically, since seldom will the limits of the arrays involved be static. That dynamic allocation costs you, the user, in execution speed; and, there will probably be more temporaries allocated than you perhaps think, again because the analysis required to avoid it is just too expensive. Now let's consider a somewhat smarter compiler, one that attempts to do some optimization, but still far short of attempting the analysis required by a vectorizer. This is typically the type of compiler you would see on a larger scalar machine, like a mini or supermini. This compiler probably will do better at detecting when the left and right-hand sides of an assignment don't overlap, and when it can avoid allocating a temporary, but it won't be perfect. It might also do some loop unrolling of those loops generated by the array statements, which will partially offset the penalty of having traded one loop for many. However, you'll still probably pay an execution penalty, because that one original DO loop might easily fit in your machine's instruction cache, but all those unrolled loops quite probably won't. You'll pay for this in more memory traffic and slower execution speed. But you'll also pay for the increased analysis required of the compiler in slower compilation speed. There are many other examples of how the array notation will adversely impact users of scalar machines. I hope this has been, at least, educational to you. 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/18/89)
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". > [...] > 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, > [...] Pass the whole descriptor by value. The level of indirection remains the same. This can be done because the rank (number of dimensions) of the array is known at compile time. Therefore the size of the descriptor is also known at compile time, and the correct code can be generated for the call.
khb@chiba.Sun.COM (chiba) (04/19/89)
In article <44400036@hcx2> bill@hcx2.SSD.HARRIS.COM writes: > >....cogent arguments deleted... > >There are many other examples of how the array notation will adversely >impact users of scalar machines. I hope this has been, at least, >educational to you. On the other hand, scalar machines with caches can acheive much better performance with array notation (that is it is possible, not that it will necessarily happen, especially in an early release). It is my experience that most codes which I encounter have not been well tuned for _any_ machine. When taking a large existing code (again on _any_ machine) I employ various profiling techniques to determine where the bottlenecks are. Even in million line programs it is typically only a handful of routines which need attention. If early scalar compilers generate naive array code, this is easily fixed for a particular code. This is not to say that much bigger speedups can't be had via algorithmic modifications (which having simpler code facilitates);nor that the array notation is my favorite feature. Arrays are an important part of scientific notation, and there is a strong need for them to be supported as part of a langauge catering to the scientific community. Cheers. Keith H. Bierman |*My thoughts are my own. Only my work belongs to Sun* It's Not My Fault | Marketing Technical Specialist -- I Voted for Bill & Opus | Languages and Performance Tools. (* strange as it may seem, I do more engineering now *)
alm@a.lanl.gov (Alex Marusak) (04/21/89)
In article <50500125@uxe.cso.uiuc.edu>, hirchert@uxe.cso.uiuc.edu writes:
%
% Doug McDonald (mcdonald@uxe.cso.uiuc.edu) writes
%
% >As to your second sentence first, it appears that right now, after some
% >changes, that it is proposed to keep all of Fortran 77. HOWEVER,
% >in the draft that was sent out for comment, it was proposed that
% >all of Fortran 77 would be in F8x BUT that one would have had to
% >assume that a long list of things (like common, equivalence, and
% >ordinary do loops(!)) would disappear from F9x. This would have meant that
% >. . .
% AAAAAAAAAAAAAAAAARRRRRRRRRRRRRRRGH! This simply isn't true! Go reread the
% public comment draft! If the rules in it are followed, the only features which
% could possibly be removed from F9x are the features labeled as being
% "obsolescent". That list is quite short! In particular, it does not
% . . .
Actually, Kurt, Mr. McDonald is quite right. The point has been made over
and over that Fortran users planning for the long haul would have to phase
out the use of obsolescent AND deprecated features. Your little nicety
on 'what can be stripped from 9x' is technically true, but it doesn't
change the stated concern one iota.
% Please, people! If you're going to complain about what's been proposed for
% Fortran 8x, try to get your facts straight and only complain about things that
% are actually there.
True. A little more understanding on our (X3J3's) part as to what the
comments are saying wouldn't hurt either.alm@a.lanl.gov (Alex Marusak) (04/21/89)
In article <50500125@uxe.cso.uiuc.edu>, hirchert@uxe.cso.uiuc.edu writes: % % . . . % AAAAAAAAAAAAAAAAARRRRRRRRRRRRRRRGH! This simply isn't true! Go reread the % public comment draft! If the rules in it are followed, the only features which % could possibly be removed from F9x are the features labeled as being % "obsolescent". That list is quite short! In particular, it does not % . . . % Please, people! If you're going to complain about what's been proposed for % Fortran 8x, try to get your facts straight and only complain about things that % are actually there. See, Kurt, here's another person who thinks that obsolescece and deprecation actually mean something. And he's strongly in FAVOR of 8x: In article <MAINE.89Apr20095120@drynix.dfrf.nasa.gov%, maine@drynix.dfrf.nasa.gov writes: % . . . % Many of the deprecated features seem frankly out of place and in % conflict with the "style" of the new language. I intend to rapidly % abandon these deprecated features when the Fortran compilers come out, % regardless of whether the formal standard retains the list or not. % It seems obvious that many of those features are in the new language % only to ease the transition (admitedly an important thing to do if any % new language is to catch on). % . . .
mccalpin@loligo.cc.fsu.edu (John McCalpin) (04/26/89)
In article <12170@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >From article <590@loligo.cc.fsu.edu>, by mccalpin@loligo.cc.fsu.edu: >> 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". Almost. It is closer to being the difference in attitudes between those who are able/willing to re-write their codes from scratch to perform well on a given architecture, and those who are not able/willing to do so. Obviously, I list myself in the former group, but there are also many university users who belong to the latter. For my codes (which are essentially 100% vector instructions), the new Fortran should compile into code which is just as efficient as the old FORTRAN, but with a lot less compiler effort. I suspect that Jim has to work on codes that are substantially larger than what I have to deal with. My current code is about 5000 lines of FORTRAN-77, or about 1300 lines of Fortran-8X. (This excludes the machine-dependent part, such as optimized FFT's, which I count on someone else providing). The code was also designed with 8X in mind. I'm sure I would feel differently if I had >10,000 lines of old code to deal with - especially if I did not write it.... >> 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, >Pass the whole descriptor by value. The level of indirection remains >the same. This can be done because the rank (number of dimensions) >of the array is known at compile time. Therefore the size of the >descriptor is also known at compile time, and the correct code can >be generated for the call. Yes, that is the obvious answer, but it seemed to me that the overhead is still a bit high because the descriptor is not trivially small. I'm not sure exactly what needs to go into the descriptor, but I think that at least the following are necessary: pointer to beginning of array section number of array dimensions (n=<7) size of dimension 1 size of dimension 2 " " " " size of dimension n (n=<3 most of the time) Increasing the size of argument lists is usually a bad thing, performance-wise, since it means that you can often not pass the arguments in registers. -- ---------------------- John D. McCalpin ------------------------ Dept of Oceanography & Supercomputer Computations Research Institute mccalpin@masig1.ocean.fsu.edu mccalpin@nu.cs.fsu.edu --------------------------------------------------------------------