Maybe some relevance to the performance nitpicking anti-semantics around here...in particular read section 4 "Problems and Solutions." -- Mark

http://www.llnl.gov/tid/lof/documents/pdf/217941.pdf

Abstract:

"In the May 1984 issue of Physics Today, Jim McGraw debated David Kuck and Michael Wolfe on the question of retiring FORTRAN.  They addressed such questions as:  Is FORTRAN the best tool for decomposing problems for parallel execution?  Is FORTRAN the programming language we should carry into the 21st century?  Are there any alternatives?  While McGraw argued forcefully in favor of retiring FORTRAN, concerns about performance crippled his position [key to the D debates! -M].  He could not rebut the claim that only FORTRAN could provide the performance required for scientific computing.  In this report, we use the current performance of ... SISAL, a functional language for large-scale scientific computing, to counter that claim.  If McGraw had had our data in 1984, he could have countered what some say is the only defense [left for] FORTRAN.  The results show that we can move beyond the constraints of imperative programming.  We can raise the level of abstraction and *retain performance*."

I think that D has the semantic capability of besting FORTRAN for numerical apps, though the current implementation is not there.

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:aqhmdo$2ovk$1@digitaldaemon.com...
> Maybe some relevance to the performance nitpicking anti-semantics around here...in particular read section 4 "Problems and Solutions." -- Mark
>
> http://www.llnl.gov/tid/lof/documents/pdf/217941.pdf
>
> Abstract:
>
> "In the May 1984 issue of Physics Today, Jim McGraw debated David Kuck and Michael Wolfe on the question of retiring FORTRAN.  They addressed such questions as:  Is FORTRAN the best tool for decomposing problems for
parallel
> execution?  Is FORTRAN the programming language we should carry into the
21st
> century?  Are there any alternatives?  While McGraw argued forcefully in
favor
> of retiring FORTRAN, concerns about performance crippled his position [key
to
> the D debates! -M].  He could not rebut the claim that only FORTRAN could provide the performance required for scientific computing.  In this
report, we
> use the current performance of ... SISAL, a functional language for
large-scale
> scientific computing, to counter that claim.  If McGraw had had our data
in
> 1984, he could have countered what some say is the only defense [left for] FORTRAN.  The results show that we can move beyond the constraints of
imperative
> programming.  We can raise the level of abstraction and *retain
performance*."
>
>

The article brings up good points about the need for a class of functions that are guaranteed to have no side effects, in order that the compiler won't have to do global analysis just to find out whether a function call can be hoisted out of a loop.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:aqmj3g$1pop$1@digitaldaemon.com...
> I think that D has the semantic capability of besting FORTRAN for
numerical
> apps, though the current implementation is not there.
>
> "Mark Evans" <Mark_member@pathlink.com> wrote in message news:aqhmdo$2ovk$1@digitaldaemon.com...
> > Maybe some relevance to the performance nitpicking anti-semantics around here...in particular read section 4 "Problems and Solutions." -- Mark
> >
> > http://www.llnl.gov/tid/lof/documents/pdf/217941.pdf