From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,HK_RANDOM_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,42b96374c851ce5a X-Google-Attributes: gid103376,public From: bglbv@my-dejanews.com Subject: Re: Ada for numerics computation (i.e. forget Fortran ?) Date: 1999/04/24 Message-ID: <8790bhslfz.fsf@bglbv.my-dejanews.com> X-Deja-AN: 470497978 References: <372083A1.45A5EB97@t-online.de> <7fqeua$ih8$1@pegasus.csx.cam.ac.uk> X-Complaints-To: abuse@freeuk.net X-Trace: nnrp2.clara.net 924993593 212.126.147.91 (Sat, 24 Apr 1999 23:39:53 BST) NNTP-Posting-Date: Sat, 24 Apr 1999 23:39:53 BST Newsgroups: comp.lang.ada Date: 1999-04-24T00:00:00+00:00 List-Id: 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.)