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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,90c3c79963d78580 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-05-10 06:54:23 PST Path: newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!134.222.94.5!npeer.kpnqwest.net!lnewspeer00.lnd.ops.eu.uu.net!emea.uu.net!ams.uu.net!news.mailgate.org!mail2news!fedelma.astro.univie.ac.at!not-for-mail From: stift@fedelma.astro.univie.ac.at (Martin Stift) Newsgroups: comp.lang.ada Subject: Re: Numerical Computation and Ada95 Date: Thu, 10 May 2001 13:54:19 +0000 (UTC) Organization: Mailgate.ORG Server - http://www.Mailgate.ORG Message-ID: <3AFA9DC2.672CAFE9@fedelma.astro.univie.ac.at> References: <9dc4sh$ru5$1@ulysses.noc.ntua.gr> NNTP-Posting-Host: fedelma.astro.univie.ac.at Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.mailgate.org 989502859 15787 131.130.36.112 (Thu, 10 May 2001 15:55:15 +0200) X-Complaints-To: fedelma.astro.univie.ac.at@abuse.net abuse@mailgate.org NNTP-Posting-Date: Thu, 10 May 2001 13:54:19 +0000 (UTC) Mail-From: stift@fedelma.astro.univie.ac.at from fedelma.astro.univie.ac.at [131.130.36.112] X-URL: http://www.Mailgate.ORG Xref: newsfeed.google.com comp.lang.ada:7467 Date: 2001-05-10T13:54:19+00:00 List-Id: >>From what you said I understand that nobody has ever compared Ada's timing >performance with Fortran77/90/95, C and C++ in programs that require lots >of arithmetic and logical operations (perhaps FFT). I think I will try to >do it when I learn Ada95 better >The issue of performance is one of my biggest worries when choosing >Ada95 over other languages, when speed is critical. Comments elsewhere >in this thread suggest that this is not normally a problem, but I >have found that great care is needed to avoid inocuous constructs which >result in slow code. Sometimes this prevents writing the code in >the most "natural" way. Things may be better now with the latest >GNAT (I developed most of my performance-critical code under GNAT 3.11, 3.12). >Of course, you need to take great care in C or C++ too. Fortran(77) seemed >to be a lot more robust in performance terms, perhaps because it was >quite limited in what you could do. Try some simple example comparisons >in your proposed environments. They may not be representative, but >at least you'll have some idea what to expect with "real" code. Well, I have had the chance to compare the numerical performance of Ada83 and of Ada95 with Fortran77 with quite satisfactory results. Back in 1994 I had a program written in Fortran77 which carried out spectrum synthesis in magnetic stars. This program had been translated into Ada83 with considerable restructuring of the code in order to take advantage of the superior expressive power of Ada83. The code did mostly number-crunching. Running the respective Fortran and Ada83 codes on a DEC Alpha under OpenVMS resulted in the Ada code being about 5% slower than the Fortran code. At that time I had 20 years experience in Fortran and 1 year experience in Ada83. In 1997 I definitely switched to Ada95, working on a Silicon Graphics Origin200 4-processor server. In the beginning the GNAT compiler running under IRIX had to use the old and slow o32 ABIs whereas with Fortran one could use the much faster new n32 ABIs. In some extreme cases, execution times could differ by as much as a factor of 3. However, when using the o32 ABIs for both Fortran and Ada95, performance was about the same to within 10-20%. The situation has greatly improved since. Although Sgi is known for its advanced Fortran compiler technology, the GNAT compiler by now performs impressively. The famous "abstraction penalty" can be encountered both in Fortran and in Ada95. The calculation of the Voigt-Faraday function, which is the most time-consuming part of my code, in Ada95 takes about the same time (within 5-10%) as with Fortran. I made another test with a celestial mechanics program which I translated directly into Ada without any substantial modifications to accomodate Ada features. Again, the program just does number-crunching, extensively using more-dimensional arrays which should be treated very effectively in Fortran. Still, with GNAT 3.13, the Ada95 version was f a s t e r than the Fortran77 version. One of the major advantages of supercomputing with Ada95 is the fact that it provides a thread-parallel model. You don't have to resort the MPI but can parallelise your code with kernel language constructs. Protected objects have very little overhead and are perfectly suitable for synchronisation. Tasks also are easy to handle. At present, I am running my codes on an Origin2000, using up to 64 processors (Amdahl's law makes it impracticable to use more processors for the problems at hand). Summarising I can say that Ada95 is a viable alternative to Fortran. It is fast and safe, the parallel constructs are easy to use. More information on supercomputing with Ada95 can be found in Stift, M.J., 1998. Astrophysical Supercomputing: Ada95 as a safe, object oriented alternative. In Reliable Software Technologies --Ada Europe '98, ed. L. Asplund, Lecture Notes in Computer Science, Vol. 1411, p. 128-139. Stift, M.J., 1998. Scientific programming with Ada95: object oriented, parallel and safe. Computers in Physics, Vol. 12, No. 2, p. 150-158. These publication give some ideas as to how the Ada95 features can be applied to (astro)physical problems. Synchronisation as presented in 1998 is somewhat outdated now, the solutions presented in the above-mentioned papers are only useful on small machines like my Origin200. They have in the meantime been replaced by much more efficient algorithms that work on large supercomputers. Martin Stift -- Posted from fedelma.astro.univie.ac.at [131.130.36.112] via Mailgate.ORG Server - http://www.Mailgate.ORG