(j3.2006) Interesting F2003-ism

Bill Long longb
Fri Feb 23 15:19:51 EST 2007


Aleksandar Donev wrote:

>Bill Long wrote:
>
>
>
>>Most of the rank-independent arguments I see in C libraries
>>are typeless buffers in routines used to just move data from one place
>>to another. Given that Fortran has intrinsic assignment for arrays,
>>libraries like these seem irrelevant to a Fortran programmer.
>>
>>
>That is where you are wrong! I am at a SIAM conference now where I heard
>at least five Fortran jokes in random contexts in public talks, mostly
>by people developing FRAMEWORKS for solving scientific problems. Things
>like coupling different PDE solvers together, meshing by a centralized
>agent that than calls other specialized solvers, adaptive mesh
>refinement libraries, automatic computation and communication
>reordering, and all kinds of other stuff. I can try to write examples if
>I had the time, but I suggest looking at the program for the SIAM
>Conference on Computational Science and Engineering program on line.
>There is tons of talks about software infrastructures.
>
>At present, all of those people are mostly concerned about calling
>Fortran-77 codes to do some compute-intensive jobs. They are trying to
>do Fortran-90 and are running into major headaches...this is what gave
>Craig headaches too...People get payed by DOE to do this but it is not
>easy. For example, AMR codes allocate memory for the refined meshes
>themselves. They use *sophisticaed* data structures---they don't just
>copy around buffers (and there are some that do, notably MPI and
>variants thereof). PETSc, which is now considered legacy code, uses
>But it needs the interop TR to do this portably. With the allocatable TR
>they may sometimes be able to do better by allowing non-alised access to
>the Fortran codes.
>

OK. I'm at least somewhat familiar with a lot of this stuff since one of
our customers does use it.   However, I would note:

1) People doing Adaptive Mesh Refinement are generally working in a
fixed number of dimensions, so the issue of rank-independent code is not
that critical.

2) The data structures are generally more complicated that just simple
arrays anyway.

3) Most of the examples noted above involve C calling Fortran which
should work pretty well with the TR as currently specified.

4) The utility of some of these complicated infrastructures (other than
as a means of employment for an army of programmers) is the subject of
significant, and at times highly contentious, debate.

\begin{soapbox}{My view is that they make programs impossible to debug
and impossible to understand.  The counter argument is that there should
be no bugs because the important code was written by "professionals" and
I, as a stupid scientist, am not supposed to understand the code - just
use it as directed and leave the real programming to those who know what
they are doing.}
\end{soapbox}.

5) Some of these projects are rigidly (and religiously) tied to C++ even
though the same thing could now be accomplished as well with f03 and
much better in the future with f08.  They will not switch languages now
that they have invested so much in C++.  The only reason they tolerate
calling f77 routines at the bottom is that the code implemented fully in
C++ is too inefficient.  I'm not sure that expanding C interop will
actually help them all that much.  [Of course, as someone who works for
a hardware vendor, the argument that "buying more hardware to compensate
for inefficient code is more cost effective than optimizing the
programs" is a net win.]

>
>I am not even an expert on these C++ infrastructure codes developed
>mostly at DOE labs, since I program very specific particle-based codes
>and they are focused on PDEs mostly. But I have been to enough talks and
>have enouigh colleagues that do to know they are very important. You
>don't see them because as I said they avoid anything above Fortran 77
>like the plague...
>
>
>

As you say, "mostly at DOE labs", and I'd add only some of them. This is
a pretty narrow community; a lot of other users of large systems are not
going down this path.  And a lot of the animosity towards Fortran is
based on some combination of ignorance and religion.  Based on the
benchmarks and applications I see (admittedly in just one corner of the
computing spectrum), most big codes are still written in Fortran and
mainly in Fortran 95.

As an aside, there was an interesting article in today's HPCWire by Marc
Snir at Univ. of Illinois about the future of programming and
languages.  There is a lot of discussion of PGAS languages (mostly
positive). Co-arrays (CAF) get a lot of mention.  Even one mention of
their improvement as part of the Fortran 2008 work.

Cheers,
Bill

--
Bill Long                                   longb at cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://j3.scs.gmu.edu/pipermail/j3/attachments/20070223/080057b6/attachment.html