(j3.2006) Interesting F2003-ism

[Bill Long]

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 
>array pointers to give Fortran 90 access to internal data-structures. 
>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