Re: Ada for numerics computation (i.e. forget Fortran ?)

[bglbv@my-dejanews.com]

mgk25@cl.cam.ac.uk (Markus Kuhn) writes:

> In article <372083A1.45A5EB97@t-online.de>, HNBeck@t-online.de (Hans N. Beck) writes:
> |> does anyone has experiences with Ada and numerical
> |> applications ?
> 
> Have you seen
> 
>   http://amok.ast.univie.ac.at/~stift/stift_home.html
> 
> which is a web page that propagates the use of Ada95 in
> astrophysics number crunching.

I had an email exchange with Martin Stift a few days ago, in which
he expressed wonderment at the fact that his stuff drew no reaction
at all for years, and then suddenly in the past few months he's
been getting lots of feedback. Nice. (But please don't overload him
with code maintenance requests: I for one am also interested in
his research on Cepheids...)

> |> Does Ada fit for this?
> 
> It think it does! You have all the types available (including complex),
> you have a better exception handling than in Fortran, and with tasks,
> you have a powerful construct for using parallel processors. 

As an experienced Fortran user who is experimenting with Ada 95 for
some (small-scale, to begin with) numerical projects, let me comment
on this.

The types are indeed available (and the type system itself is much
better than that of Fortran in my view, although I'm quite certain that
most of my colleagues would disagree with me on this). The array
operations, however, are not. Some of them can be implemented in
user-defined packages, but I wouldn't want to bet that Ada compilers
are very good at optimising away array temporaries. (Many Fortran
compilers also leave to be desired in this area, but at least the more
serious vendors are working on this sort of thing.) I've found that
GNAT, for example (3.10p; I haven't had time to upgrade to 3.11 yet),
seems to require a lot of stack space to execute something like
   Big_2d_Array := (others => (others => 0.0));
as if it was allocating a temporary for the right hand side, then
copying the result to the left hand side. Recoding this as two nested
loops got rid of the stack overflow. This was all with -O3, by the way.

As for Ada tasking making it easier to program parallel processors,
I don't buy that claim. The problem with Ada tasking is that the
programmer has to make it explicit. This is in stark contrast to
Fortran's pragma-based schemes (OpenMP, HPF) where the compiler takes
care of the details and the programmer only supplies a few hints.
Ada and Fortran are on more of an equal footing where explicit
message-passing parallelism (based for example on the MPI standard)
is concerned. But this paradigm is better described in terms of Annex E
stuff than of tasking constructs.

Perhaps an OpenMP-style parallel Fortran program could be translated
using Ada tasks, at least in some cases. The obvious platform to
benchmark this on would be SGI. I don't have time to try it myself
(and I've always steered clear of parallelism as much as I could,
since it's a big sink of developer's energy), but perhaps someone
else will. The results would be well worth publishing, if that can
help.

>                                                              Ada is
> certainly much better suited than C, which thanks to the array/pointer
> duality prevents many of the strong optimizations that number-crunching
> applications need on modern RISK architectures. C implicitely assumes
> that arrays have to be stored always in RAM (as opposed to registers),
> while compilers can handle non-aliased Ada arrays much more flexible.

Yes, there is no doubt that Ada is superior to C. But that's a weak
strawman, as Fortran 95 is itself so much better than C that no one in
his right mind even tries to put them on equal footing. The question
is Fortran 95 vs. Ada 95 vs. C++ 98.

Also, production C compilers from reputable vendors usually support
at least a command-line option (sometimes also a pragma) to permit
no-aliasing assumptions.

> (I actually wonder, whether GNAT 3.11p does produce more efficient
> code for non-aliased arrays than the corresponding C code, or whether
> GNAT limits itself to the optimization capabilities of gcc.)

The gcc back-end is being improved in this area to support g77 (and
GNAT too, I suppose), so the two possibilities are not mutually
exclusive.

> |> It's not only a question of types available, but also
> |> of efficiency (speed) of the compilers.
> 
> You get Ada compilers today that are quite comparable in efficiency
> with C compilers. On more exotic architectures such as super
> computers, you might not find the same level of optimization yet
> as it is available for Fortran 77 compilers. It depends a lot on the
> architecture.

And on the coding style. (This is reportedly also true of C++,
and in any case it should come as no surprise.) There is a learning
curve both for users (who have to learn about the relative efficiency
of various approaches) and for compiler developers (who tend to work
hardest on optimising the constructs they see in user code, and will
need to see a lot of number-crunching applications in Ada for their
guidance). Exactly the same issues arise with Fortran users and
Fortran compiler writers, the difference being that progress has been
more rapid because the user base is larger. (To avoid misunderstandings,
I'll underline: _for classical number-crunching applications_. I'm not
in a position to comment on other application domains.)

At this time I wouldn't commit to Ada for my heavily CPU-bound applications
(which I'm not going to recode from scratch anyway, for obvious reasons).
But I have no doubt whatsoever that something like "Numerical
Recipes in Ada 95" would be appropriate. (Well, except for the fact
that Numerical Recipes code is meant as an illustration of the various
techniques involved, not as industrial-strength reusable software.)

If you *really* want to "sell" Ada to a Fortran user, show him/her how
to instantiate generics. (It helps if you have useful generics at
hand, and that's where something like Numerical Recipes would fit
into the picture.)

And of course Ada is a perfectly fine choice for a number of support
tools (visualisation, file format conversion, etc.) that are also part
of supercomputing's bread and butter. That alone can make it worth
learning. Recently I got a colleague interested in learning C simply
by solving an endianness problem he had with a few routines out of my
toolbox, which I customized under his eyes. Had my solution been in
Ada (and it would have been more elegant in Ada), I might just as
easily have hooked him on that. (Well, except I couldn't have pointed
him to an Ada reference book in the reading room the way I did with
K&R.)