From J.L.Schonfelder@liverpool.ac.uk Tue Aug 8 13:08:00 1995 Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk) by dkuug.dk with SMTP id AA02141 (5.65c8/IDA-1.4.4j for ); Tue, 8 Aug 1995 13:08:00 +0200 Received: from pop.liv.ac.uk by mail.liv.ac.uk with SMTP (PP); Tue, 8 Aug 1995 12:07:34 +0100 Received: from jlspc.liv.ac.uk (jlspc.liv.ac.uk [138.253.102.118]) by pop.liv.ac.uk (8.6.12/8.6.6-ajt-2) with SMTP id MAA29547; Tue, 8 Aug 1995 12:02:06 +0100 Date: Tue, 8 Aug 1995 12:07:11 OBS From: Lawrie Schonfelder Subject: Re: (x3j3.1995-315) Re: Parameterized Derived Types To: Richard Bleikamp Cc: SC22/WG5 members Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Charset: ASCII X-Char-Esc: 29 I have just returned from vacation and seen this and feel I must reply to some of the content which is seriously misleading. On Mon, 31 Jul 95 16:28:59 CDT Richard Bleikamp wrote: > From: Richard Bleikamp > Date: Mon, 31 Jul 95 16:28:59 CDT > Subject: (x3j3.1995-315) Re: Parameterized Derived Types > To: x3j3@ncsa.uiuc.edu > > I've tried to summarize below why I feel the parameterized datatypes effort > should NOT be split off and worked on by an ISO sub-committee. And why > parameterized datatypes are perhaps not a very important addition for F2000. > > I've also included some more general philosiphizing (sp?) about what F2000 > needs, and other concerns I have about Fortran's future. > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > A large part of my concern has to do with the previous proposals, partly (or > wholly ?) written by Lawrie, which were part of Fortran 8x. Lawrie claims > that the previous parameterized datatype proposal would not be difficult to > implement, nor would it it necessarily result in slow code. I disagree with > both of these claims. > > > >From X3J3/159: Minutes from meeting 88 (November 1983) > > page 25 (scribe notes from a discussion of a parameterized datatypes > proposal, 88(9)JLS-2) > > Clinkenbeard: Such a facility would be very expensive to implement. For example, attributes for precision may be > parameterized and because at compile time the > actual attributes may not be known, this is in > effect a generic precision capability. Also, it > appears to be expensive with parameters that > are extents of arrays in structures. Everything > in the structure seems to require a dope vector and > a dope needs to be consulted to generate an address. > > Answer: The expense seems to be no different than for > facilities already accepted. This is reporting historic information entirely out of context and is therefore totally irrelevant to consideration of the proposal last seen by WG5 and about which my comments were made. The above was related to the old PRECISION,RANGE parameterisation proposals for floating point datatypes. This proposal did indeed have a compile time overhead of potential explosion of version. The overhead was inherent in the then parameterisation structure for intrinsic types that was accepted at the time. Parameterised derived types then and now do not add significant overheads above those required to handle the intrinsic facilities. When operating as a politician I expect to be misrepresented and quoted out of context. This is a well known if disreputable political tactic. In a technical area such tactics are unacceptable. If Rich was unaware of the irrelevance of the historic exchanges, then he is not guilty of deliberate misrepresentation and as he was not I think on the committee at the time I rather expect this to be the case. It does however demonstrate the danger of selective quotation out of the original context. > > > >From X3J3/161: Minutes from meeting 89 (Feb. 1984) > > page 26: A more modest proposal was discussed (I long since discarded > the actual papers, but kept the minutes). From the discussion > and proposed edits, it appears dummy arguments could still > inherit certain attributes from the actual argument. This either > requires runtime branching, or the processor must generate a copy > of the procedure for the cross product of all possible > combinations of "assumed" attributes for all such dummy > arguments (could be a very large number of copies of the > procedure). > > S8.108 (june 1988) contains a version of the parameterized datatype stuff, > which I believe still required: > 1) runtime branching to accomodate differing datatypes, or > 2) a possibly combinatorial explosion of versions of a procedure > which had dummy args with a "*" used for > certain "type-param-value"s (an assumed type parameter). > > I didn't have the time to research whether or not S8.108 still required some > sort of dope vector for derived types. If so, this clearly imposes some > performance penalty, but perhaps not as much as for assumed shape > arrays. This is primarily an implementation cost issue > (modest incremental cost i suspect, though it complicates the calling > sequence for derived types, similar to assumed size arrays). > > Requiring the processor to provide/compile all possible "versions" of > a procedure with assumed type arguments is overly expensive in terms of > compilation time and size of the object file produced. I might still be > tempted to use this implementation model, because its the cheapest way to do it > without imposing runtime performance penalties. But the impact on program > load times is not negligable, and it substantially complicates the compilation > process/environment. > Note, the proposal recently before WG5 does not allow assumed parameter values for KIND, any more than F90 does for intrinsic types (This is the main reason why there is a distinction between KIND and LEN-style parameters). All version of a procedure which have different KINDs for dummy arguments must be handles by explicit overloading, as per intrinsic types. Assumed parameters are allowed only for LEN-style parameters which are restricted to determining array shapes and character lengths etc. of components. This is not significantly different in implementation problems than assumed shape arrays or assumed character lengths. > Another alternative is to delay compiling the problem procedure, until it > is time to link the program, at which time the compiler could determine > which "flavors" of the procedure were actually required, and it could > compile them then (at link time). Certain C++ implementations do this. > This is a MAJOR complication for the implementors. It requires changes to > object file formats, a vastly more complicated pre-link process, and > a smarter debugger. Although the compilation times and object file space > requirements are improved, some of the overhead is now transfered to the > linking (or pre-linking) process. And the implementation cost is higher. > > Inserting runtime branches and alternative code for the assumed type arguments > is (perhaps) a little easier to implement (i'm not sure of this), but imposes > runtime performance penalties which I feel are prohibitive. > > None of these implementation approaches is low cost. > > I personally would have prefered a functionally more limited capability > for dummy arguments, reducing the number of possible versions of the > procedure required, or allowing a runtime decision approach with limited > overhead. See above and the proposal in the WG5 Edinburgh papers. The proposal does exactly this. There is no implication of the compiler having to generate different versions for different parametr values. KIND style parameters remain as for intrinsic types entirely static and LEN-style parameters behave exactly like character LEN and simply carries a variable that controls "loop" operations. > > > This history with F8x and parameterized datatypes is why I am so concerned > with having a small, somewhat separate, ISO sub-committee go off and design a > new and complicated feature. > > My main concern with the ISO tech. report process is the lack of input > from the X3J3 membership as a whole, while the proposal is being developed. > Even though X3J3 members are allowed to participate, the time demands too > participate meaningfully on both X3J3 proper and a separate ISO sub-committee > make it impossible for me to do both. > > Certain "enhancements" intuitively feel better suited to the ISO tech. report > process, but parameterized datatypes is not one. The committee has not > discussed this issue in a long time, there is no committee agreement on a "good" > approach, and the Fortran language and standard itself are likely to be impacted > substanially. I want the whole X3J3 committee to be involved with this > particular addition to the language. > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Partially related comments: please pardon the hard to read cutting/pasting: > > >> > Rich B wrote: > >> > Most of the committee would prefer a different balance between > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> > cost, speed, and functionality. > >> > > >> Craig (i think) wrote: > >> Yes, most of the committee would prefer this, but what do the USERS of > >> Fortran (i.e., our *CUSTOMERS*) want? Does anyone have any insight on this > >> issue? > >> > >Lawrie wrote: > >Users need functionality at adequate speed and above all they need to be able > > ^^^^^^^^ > Adequate speed is not sufficient. Fortran must remain the performance king > to survive. That is Fortran's niche. > > ALL languages will have a niche in the future. Strenthening Fortran's hold on > the performance niche, while accomodating other languages, is the only way to > ensure Fortran's survival. Without this, there is no reason to use > Fortran anymore. > > Many users have already abandoned Fortran except when performance is crucial. > Partly because you can't hire Fortran programmers fresh out of college anymore. > But trying to make Fortran more appealing to college instructors is not the > right approach. Preserving Fortran's niche, and strengthening its hold on the > high performance market is the most important first step. We don't need to > add lots of new modern features. > > > >to interface their Fortran with modern GUI interfaces X and WINDOWS. This > >probably means easy interfaces to C/C++ libraries. Without capability Fortran > >will become >a HPC niche player and will eventually die as a major programming > >tool. > > This is clearly required soon! Since Fortran is in the number crunching > business, it needs a standard way to export the generated numeric results to the > user, and get input from the user. In todays world, the obvious candidates > are several assorted windowing systems, and AVS style packages. > A standard binding mechanism to 'C' (and possibly C++) will provide these > capabilities, for a modest effort and cost, and should be a very high priority. > This is far more important than parameterized datatypes, and a better > candidate for a sub-committee design effort. > > Exception handling is also fairly high on my wish list. > > HPF support may become important in the future, but it isn't yet. > > - - - - > > On the cost of implementation issue, it is clear that Fortran 90 has changed > the way hardware vendors implement compilers. Many fewer hardware vendors > have written their own compiler from scratch (or modified an existing f77 > compiler) than I expected. > Quite a few computer companies (Sun, Microsoft, HP, DEC, to name a > few) have decided to purchase outside technology, in spite of a long history > of problems with this approach. This is primarily due to the huge development > cost for a Fortran 90 compiler (i don't think anyone has developed a production > quality compiler for <20 man years, except NAG). This is why Fortran 90 > compilers have taken so long to appear. You just can't develop them any quicker > unless you have the resources of IBM. Even when a vendor uses a 3rd party > front end, the acquistion costs and ongoing expenses of a 3rd party front end > are a significant strain for many organizations. > > This cost of implementation issue is also a major concern for F2000. > If F2000 requires many more man years of effort to develop, it will delay > the introduction of F2000 compilers much longer than is desirable, and > will push the cost of compilers up higher than the already high costs for > Fortran 90 compilers. We may even see an Ada-like compiler problem. > A few front ends will be written (Rational, Verdix), and most everyone else > will be forced to buy one of those, due to prohibitive development costs. > As the number of front end suppliers goes down, the cost goes up. So the end > user cost also rises. > > Fortran does not have the same size user base as "C" to spread these development > costs across. We need to keep this in mind when adding new language features. > Every new feature we add raises the implementation cost, and which directly > impacts the price the end user has to pay. > > Rich > An assumption underlying some of Rich's concern (in addition to his serious misunderstanding of the current proposal) appears to be a tacit acceptance that Fortran is already merely a minor niche language for high performance computing. If this is irrevocably true then I for one would say the time had come to throw in the towel. Such a language in my opinion is doomed to extinction. It might take a decade or two to die but die it would. It is only as a general purpose end-user language for scientific/engineering application development can Fortran survive and prosper. My view is that F90 was a move in the right direction but suffered by being a shade "too little too late". F95 is definitely too little too late and unless a number of things get into Fortran implementations well before F2000 processors start appearing Fortran is doomed. The TR2 approach was suggested as a means of speeding up the development process and to introduce more resources into that process. There is considerable language design and standardisation expertise in the ISO world, J3 does not have a monopoly in this area. The TR2 approach does not exclude J3 members. They are positively encouraged to be involved along with people from other member bodies. -- Dr.J.L.Schonfelder Director, Computing Services Dept. The University of Liverpool, UK e-mail J.L.Schonfelder@liv.ac.uk phone: +44(151)794-3716 fax: +44(151)794-3759