Fortran - Fortran 2008 (was Re: Statement function host association)

Author

Fortran 2008 (was Re: Statement function host association)

beliavsky@aol.com

2005-05-18, 4:00 pm

Dan Nagle wrote:
> Hello,
>
> Actually, the vote in Delft was to delete statement functions
> in the 2008 standard.

Has the committee voted to remove any other features from Fortran 2008?

In the June 2005 issue of C/C++ Users Journal, P.J. Plauger wrote about
the C standards process:

"It was a busy w

for WG14 [the C standards committee]. No, the
committee has still not begun work on a new version of the C standard.
The sentiment remains that C99 has yet to catch on widely enough in the
industry. The last thing anyone wants is the prospect of yet another
version looming on the horizon. [...]"

"Part of what kept us so busy [at the latest committee meeting] was
answering Defect Reports. These are official queries and/or complaints
about the meaning of the current C standard."

A similar approach to standardization may also be best for Fortran,
although
the C community is probably dominated by language conservatives, with
the progressives having moved to C++ long ago. (I don't mean either
"conservative" or "progressive" pejoratively -- there is a need for
both types of languages.)

Keith Bierman has discussed the conflict between Fortran conservatives
and progressives in the F90 standard process in a blog entry at
http://blogs.sun.com/roller/page/kh...ds_do_s_and_don ,
which is excerpted below. I wonder who the "one particular individual"
is that Bierman mentions in the last paragraph.

"Now, as to the

case of Fortran (I was on the Committee for a dozen
years, and had been a formal observer for another couple before that)
it's a long

saga (and Brian M

, who Bill references, was hardly
an unbiased observer to say the least).

To make a long and painful story short enough to learn key lessons
from:

(1) The Committee was roughly divided into two nearly equal factions,
let's call them the Progressives and the Conservatives. The
Progressives wanted to create a throughly modern language that would
run all existing Fortran codes, and preserve the performance
characteristics that made Fortran valuable to the high performance
crowd. The Conservatives felt that it was virtually impossible to
ensure either of those requirements (since all real codes depended on
various vendor extensions and implementation details, and the new
Standard was radical enough to require a rewrite of the compilers) and
that the appropriate behavior for the Committee was along the lines of
what Bill suggests. (In the interest of honesty, I was on the wrong
side of that issue at the time. I was a Progressive. I repented after
it was too late).

(2) Due to the voting rules, the Committee lurched from one side to
the other, taking what had been a pretty coherent (if overly
ambitious) document, tossing nearly all of it away (when the
Conservatives were on the upswing) and then putting each feature back
in piecemeal (losing the structural integrity of the original) over
the course of many years as the Progressives recovered their majority.
This was the worst of all worlds, a major update, which was very late
and no longer done "well".

(3) Both sides were, alas, in agreement that we needed to keep
everyone in the One Big Tent. That is, to keep all of the warring
factions together. Had we split into two efforts, we would have had
two stronger languages. Just as Algol begat C, which begat C++ which
begat Java, we would have had something like Classical Fortran as the
result of the Conservatives, and something similar to Mathematica for
the Progressives (well, probably not an entire environment, but a
modern language without the baggage). Both could have been done
faster, and probably better.

(4) An example of what happens when you have two closely matched
sides, there were two different user requirements for a "bit"
datatype. There were two factions on the committee. As a result, no
bit datatype made it into the language. The needs didn't go away; but
they remain unrequited 20 years later....

But hindsight is better than foresight.

I think it worthy of mention that even during the worst of the
battles, the individuals remained cordial and friendly relations were
the norm. This was a tribute to the professionalism and to the culture
that the Committee had bulit up and maintained over the course of
several "generations" of membership.

This all came to an end, long after the camps largely evaporated, due
to one particular individual's (a newcomer at the time) influence. It
was a very striking lesson to me in human dynamics; the power (albeit
negative) of one."

Michael Metcalf

2005-05-18, 4:00 pm

<beliavsky@aol.com> wrote in message
news:1116416464.806608.184510@g47g2000cwa.googlegroups.com...
> I wonder who the "one particular individual"
> is that Bierman mentions in the last paragraph.
>

Presley Smith (Convex).

Regards,

Mike Metcalf

Ron Shepard

2005-05-18, 4:00 pm

In article <d6fbk9$ocq$02$1@news.t-online.com>,
"Michael Metcalf" <metcalfmetcalf@compuserve.com> wrote:

>
> Presley Smith (Convex).

From what I heard at the time, Convex thought it had a very good
optimizing compiler for f77 code for their hardware. They had
worked very hard to develop this new technology. If some of the new
features such as array syntax had been implemented (this is about
1985-1988 we're talking about), then that would have allowed their
competitors to catch up easily without the same effort or
investment. By stalling the standards process for the next
generation of fortran, they could maintain their perceived advantage
over their competitors.

Other vendors were involved in this process too. DEC and IBM
neither had vector hardware machines at that time (this was before
the ALPHA and RS6000 chips), so they considered the RISC and vector
machines their main competition. Stalling f8x meant keeping their
customers locked in a little longer before moving into the
RISC-based workstation market that was on its way.

Back then, for the most part, each hardware vendor developed its own
compiler. Cray developed its own software, with all kinds of
extensions designed to exploit its hardware. The same goes to CDC
and ETA, two other vendors with high-performance, but quirky
hardware. If you ever looked at CDC Cyber205 fortran code, you
might have a hard time recognizing it. The last thing these vendors
wanted was a way for their customers to write portable code that
performed well because that would put them at risk of losing
business to their competitors. The proposed f8x (in that 1985 to
1988 time period) was perceived to allow that kind of portable code
to be written. These days, not only are there hardware-vendor
compilers, but also there are numerous independent commercial
cross-platform compilers and g77/gfortran/f95 free-source
cross-platform compilers. In many ways, fortran seems to be
healthier and more robust now, when it is clearly a minority
language, than it was in the 80's when it ruled the day.

It is ironic, and perhaps a little puzzling, to me that even after
15 years or so of the new language features, array syntax still has
not shown its potential. Even now, if you really want good array
performance, you should use BLAS routines, or in some cases, write
f77-style loops instead. Of course, array syntax has other
advantages, such as clarity and simplicity. Some vendors (e.g Intel
and ABSOFT) distribute tuned BLAS libraries with their compilers,
and those libraries perform better than their intrinsic array
operations (such as matmul()). Even in cases where a source-code
level substitution could be made from matmul() to dgemm(), the
vendors have not bothered to make even these simple kinds of
optimizations.

$.02 -Ron Shepard

Richard E Maine

2005-05-18, 4:00 pm

In article
<ron-shepard-1E1C40.10550218052005@comcast.dca.giganews.com>,
Ron Shepard <ron-shepard@NOSPAM.comcast.net> wrote:

> In article <d6fbk9$ocq$02$1@news.t-online.com>,
> "Michael Metcalf" <metcalfmetcalf@compuserve.com> wrote:
>
> ...Convex... By stalling the standards process for the next
> generation of fortran, they could maintain their perceived advantage
> over their competitors.

I had some related "issues" with Presley a little after that time. This
was before I was on J3. I didn't then know anything about his prior
interactions with J3.

But as a prospective Convex customer, one of the things I was looking
for in a system was an f90 compiler. I knew that it was a bit early for
most vendors to necessarily have a released f90 compiler yet, but I at
least wanted to hear about their plans for one, or even 3rd party plans
for their machine. I wanted a machine that I was reasonably confident
that I'd be able to run f90 code on in the reasonably near future.

The Convex sales rep offered to have Presley come out and explain to me
why I didn't want an f90 compiler. (I'm sure that the real reason was
that they didn't have one so I must not want one, but I doubt that would
have been quite the way it would have been explained). I declined the
"offer" and was, in fact, a bit annoyed by it. I figured that, as the
customer, I'd tell the vendor what I wanted, thank you very much. Maybe
what I wanted was unwise, but it was still what I wanted, and that's the
way this customer-vendor thing works. Since other vendors could at least
tell me about f90 compiler plans and Convex wanted to talk me out of it,
that pretty much ruled Convex out from further consideration on my part.

And then very soon after that, Presley posted to the wg5 mailing list (I
still have copies of the thread - let's see - it was in March of 1992)
giving a wildly inflated number of users that he claimed to represent.
Can you guess how he claimed to represent 25,000 Fortran programmers?
Well, they had sold about 1,000 computers to 500 customers. Estimate
that each of those customers probably has about 50 Fortran programmers,
so that is 25,000 Fortran programmers that are his customers. And he
personally knew that every one of those 25,000 programmers agreed with
him on the points he was advocating. My very biased interpretation of
his point was that execution speed was absolutely the only concern,
trumping everything else, including such "trivia" as getting the right
answers. (I said my interpretation was biased, but that's sure the way I
thought he came over).

Quoting from my own response at the time

> I represent a viewpoint almost diametrically opposed. I am, of
> course, concerned with performance, but it is distinctly not my
> highest priority. My highest priorities are divided more among areas
> like code reliability and maintainability and programmer productivity.
> These are why I view things like modules and several of the other new
> f90 features as big improvements.
>
> I have very little interest in code that runs very fast, but gets
> wrong results. Believe me, I have seen many examples of such codes,
> sometimes codes that have been in production use giving wrong results
> for years. I view it as a very serious concern, not an academic debate.
>
> I don't intend to argue what set of priorities is "best"; such
> arguments tend to become pointless flame wars and this particular one
> is not new. I only mean to suggest that there does exist a
> significant group of users with priorities like mine. I am one and I
> know others. I also know users with priorities more like those
> Presley describes. I won't invent unsupportable numbers or
> percentages.
....
> This [Presley's claim] is awfully speculative. We jump from a presumably
> accurate number
> of systems through a speculation about the numbers of programmers,
> an assumption that all of these are Fortran programmers, add a
> blanket claim that all (or at least some unspecified large percentage)
> of these...

> I simply can't believe that all of Presley's customers are quite so
> unanimous. I can't find such unanimity in my own branch, much less
> such an impressive number as 25,000 people. I think I'm counted among
> Presley's 25,000. NASA Ames has several Convex machines and our site
> has been considering one. (Though I've recently been getting more
> insistent with their sales reps that if I can't run f90 on the
> machine, I'm not interested - trying to play my part in this "market"
> that will decide the true fate of f90). If I was counted, perhaps you
> should revise that figure to 24,999.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Steve Lionel

2005-05-18, 4:00 pm

On Wed, 18 May 2005 10:55:02 -0500, Ron Shepard
<ron-shepard@NOSPAM.comcast.net> wrote:

>Other vendors were involved in this process too. DEC and IBM
>neither had vector hardware machines at that time (this was before
>the ALPHA and RS6000 chips), so they considered the RISC and vector
>machines their main competition. Stalling f8x meant keeping their
>customers locked in a little longer before moving into the
>RISC-based workstation market that was on its way.

This is utter nonsense, at least as far as DEC was concerned. DEC certainly
did have vector hardware for several of the VAX models. I should know, as I
was project leader for the VAX vectorizing compiler for five years. But even
if it didn't, there was not the slightest thought about "stalling" F8X for
competitive reasons. DEC also had its own RISC systems based on MIPS chips.

The notion that standardizing a language that included array syntax would pose
a competitive threat is absurd. As all of us who lived through that era can
attest, it took years for vendors, even those (such as DEC) with existing
vectorizing compilers, to start to do a good job optimizing the peculiar
semantics of F90 array operations, which were very different from traditional
DO loops.

DEC was actively involved in the standardization process for F90. DEC did vote
"no" at the first level because they wanted to see more standardization of
common extensions. That did not stop DEC from developing what came to be a
widely respected F90 implementation.

I am certainly not privy to the motives of the other vendors named here, but I
would be quite astonished if they saw standardization of F90 as a thread to
their installed base.

The above is purely my personal opinion and is not intended to represent the
position of my current employer.

Steve

glen herrmannsfeldt

2005-05-18, 4:00 pm

Ron Shepard wrote:

(snip)

> It is ironic, and perhaps a little puzzling, to me that even after
> 15 years or so of the new language features, array syntax still has
> not shown its potential. Even now, if you really want good array
> performance, you should use BLAS routines, or in some cases, write
> f77-style loops instead. Of course, array syntax has other
> advantages, such as clarity and simplicity. Some vendors (e.g Intel
> and ABSOFT) distribute tuned BLAS libraries with their compilers,
> and those libraries perform better than their intrinsic array
> operations (such as matmul()). Even in cases where a source-code
> level substitution could be made from matmul() to dgemm(), the
> vendors have not bothered to make even these simple kinds of
> optimizations.

Array syntax can be hard for compilers. The simple cases, such as

A=0

aren't much of a problem, and may or may not be easier to read.

It isn't hard to write an array expression that requires temporary
arrays to evaluate, but that wouldn't require one in DO loops.

Fortran requires that array expressions are evaluated as if the
entire expression is evaluate before being assigned to the destination.
PL/I requires that array expressions are evaluated as if they are
done one element at a time, and changes take effect at that time.
Both cases can make optimizing array expressions hard.

-- glen

Michael Metcalf

2005-05-18, 8:58 pm

"Richard E Maine" <nospam@see.signature> wrote in message
news:nospam-91DAEC.10143918052005@news.supernews.com...
> In article
> <ron-shepard-1E1C40.10550218052005@comcast.dca.giganews.com>,
> Ron Shepard <ron-shepard@NOSPAM.comcast.net> wrote:
>
>
> I had some related "issues" with Presley a little after that time. This
> was before I was on J3. I didn't then know anything about his prior
> interactions with J3.
>
> But as a prospective Convex customer,

.... CERN was one too, and we made similar noises. So, too, the U. of
Liverpool. I have now found my notes for Smith's first meeting, in May 1988.
Two quotes, which support Keith Bierman's original comments:

1) "And do as adversaries do in law,
Strive mightily, but eat and drink
as friend." (The Taming of the Shrew)

2) "Presley Smith, known as the organiser of Travellers Inc's lawsuit
against the Cobol committee a few years ago, joined X3J3 as the new
representative of Convex. The only document he brought with him to the
meeting was a copy of the standing rules of procedure." [Because of this
lawsuit, X3J3 lived in real fear litigation.]

He tried to pack the September 1988 WG5 meeting in Paris with someone from
Convex France, who was then asked to leave by the official French delegates
who had not been asked let alone informed.

I would, incidentally, support Steve Lionel's interpretation of DEC's role.
Kevin Harris made outstanding contributions to Fortran 90.

Regards,

Mike Metcalf

2005-05-19, 8:58 pm

beliavsky@aol.com wrote:
>
> (1) The Committee was roughly divided into two nearly equal factions,
> let's call them the Progressives and the Conservatives...
>
> (2) Due to the voting rules, the Committee lurched from one side to
> the other...

Sadly, the state of the (mis)language shows it!

"The committee met to approve your idea. But first we had to approve the
approval, providing everyone agreed to disagree to approve the agreement
which approved the approval agreement. After that, things got
complicated."
- R. Glassbergen

....and, "when an idiot screws up, it takes a village (of pros) to fix
it"
- unknown

Sponsored Links