On Tue, 2014-03-25 at 19:33 -0600, Keith Bierman wrote:
> 
> On Tue, Mar 25, 2014 at 6:00 PM, COMP-FORTRAN-90 automatic digest
> system <[log in to unmask]> wrote:
>         I know f# can't compete with Fortran on raw speed etc. But
>         does a well thought out functional language have some fine
>         things to offer the scientific programming community?
>         I'm interested to know what people think.
>         D
> 
> I recall some colleagues using a parallel prolog in the early
> hypercube days; sadly I don't recall any stunningly good results. The
> fundamentally great practical benefit is automatic exploitation of
> parallelism. The fundamentally big flaw, is no control over
> evaluation, so numerics are problematic.
> 
> 
> Thus, something like JohnG's ubox or interval arithmetic with a
> functional language would be an interesting multidisciplinary research
> problem with some interesting upside potential.

Dave Cann wrote an article in Communications of the ACM(35), 8 (August
1992), describing experiences with SISAL.  He coded Cray's eight
favorite Fortran benchmarks in SISAL, which produced C code.  Run times
were similar with one CPU.  With four or more Y-MP/864 CPU's, the suite
of them finished faster in SISAL.  Individually, some were remarkably
faster in SISAL (a factor of 5.7 in one case), and a few were a bit
slower.  Generally, the more complex the program, the greater the speed
advantage of SISAL.

SISAL 2.0 had some defects that were proposed to be addressed in SISAL
3, but funding was withdrawn and the team was disbanded.  Haskell and pH
(Haskell's convergence with with Arvind's "id") are attempting to fill
the gap, but I do not know of efficient implementations.

Cann remarks "parallel macnines will not only provide massive
parallelism, but will present programmers with a combinatorial explosion
of concerns and details; the imperative programming model will continue
to hinder the exploitation of parallelism."  Coarray Fortran is a step
in the direction of addressing some of the problems, but it provides
only very coarse-grain SPMD parallelism, and might well be the biggest
step possible in the imperative paradigm.

At a conference entitled "High Performance Functional Computing" in
April 1995, one speaker presented his Master's thesis project, which was
a compiler from APL to Sisal.  Unfortunately, the presentation didn't
appear in the proceedings.  I asked one of the organizers, and he didn't
remember who presented it, saying "Maybe a guy from Canada?"  An
APL-to-Sisal translator would have given a high-performance APL,
something that one usually regards as an oxymoron.

Peter Denning and Jack Dennis's article "The Resurgence of Parallelism"
in CACM(53), 6 (June 2010) pp 30-32, also available at
http://cacm.acm.org/magazines/2010/6/92479-the-resurgence-of-parallelism/fulltext, is a worthwhile read in this context.  Importantly, they remark that atomicity and mutual exclusion are not sufficient for determinacy.  They continue "Determinacy is really important in parallel computation. It tells us we can unleash the full parallelism of a computational method without worrying whether any timing errors or race conditions will negatively affect the results."  Coarrays and related facilities in Fortran address some of the problems that Denning and Dennis note, including atomicity and mutual exclusion, but the determinacy, and therefore the correctness, of the program continues to rest more than it ought on the shoulders of the programmer.

They also remark that a study by researchers at Brown University and
General Electric Research Laboratories produced a set of reports on a
"contour model" of nested multitask computations in 1971.  Those reports
give a remarkably clear picture of a parallel programming runtime
environment that would suit today's languages well and would resolve
many contemporary problems considered as "research challenges."  This
study was reported in ACM Sigplan Notices 6 (Feb 1971) pp 171-190.  It
is a tragedy these ideas have disappeared from the curriculum.