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-Thread: 103376,6609c40f81b32989 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news4.google.com!feeder2.cambriumusenet.nl!feed.tweaknews.nl!138.195.8.3.MISMATCH!news.ecp.fr!news.in2p3.fr!in2p3.fr!not-for-mail From: Vincent LAFAGE Newsgroups: comp.lang.ada Subject: Re: Why is Ada considered "too specialized" for scientific use Date: Thu, 08 Apr 2010 15:40:10 +0200 Organization: In2p3 Message-ID: References: NNTP-Posting-Host: ipnnarval.in2p3.fr Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ccpntc8.in2p3.fr 1270734011 4576 134.158.92.7 (8 Apr 2010 13:40:11 GMT) X-Complaints-To: newsmaster@cc.in2p3.fr NNTP-Posting-Date: Thu, 8 Apr 2010 13:40:11 +0000 (UTC) User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) In-Reply-To: Xref: g2news1.google.com comp.lang.ada:9931 Date: 2010-04-08T15:40:10+02:00 List-Id: Nasser M. Abbasi a �crit : > I was browsing the net for scientific software written in Ada, and came > across this strange statement: > > http://farside.ph.utexas.edu/teaching/329/lectures/node7.html > > "Scientific programming languages > What is the best high-level language to use for scientific programming? > This, unfortunately, is a highly contentious question. Over the years, > literally hundreds of high-level languages have been developed. However, few > have stood the test of time. Many languages (e.g., Algol, Pascal, Haskell) > can be dismissed as ephemeral computer science fads. Others (e.g., Cobol, > Lisp, Ada) are too specialized to adapt for scientific use. > > ...... > > The remaining options are FORTRAN 77 and C. I have chosen to use C " > > I find this strange, because I think Ada can be the best programming > language for numerical work. So, I do not know why the author above thinks > Ada is "too specialized to adapt for scientific use". Is there something in > Ada which makes it hard to use for scientific programming? > > The main problem I see with Ada for scientific use is that it does not have > as nearly as many packages and functions ready to use output of the box for > this, other than that, the language itself I think is better than Fortran > and C for scientific work. > > (the above quote is from a course on Computational Physics at University of > Texas at Austin, may be I should write to the professor and ask him why he > said that, but I am not sure I'll get an answer, my experience is that most > professors do not answer email :) > > --Nasser just my 2 (numerical) eurocents I have been developping some Fortran (77) code during my PhD (17 years ago). It was a basic MonteCarlo Code for simulation of electron-positron collision. 1001 SLOC (physical Sources Lines Of Code, measured with sloccount) Not big, most work went into chiseling the analytical low-level expressions so that the numerical approach would be used at its most. No dedicated simplification or hardware related optimisation beyond what the compiler provides with -O3. Not much software engineering: only using Fortran 77 with COMMON thought as objects, and a minimum modular approach. The result was fast, but it would be arrogant boasting to describe how much ;-) Time passed and then Open MP appeared. I wanted to test my old pal reference code on my brand new two-core CPU, without much effort, I thought. To ease the move to parallel code, and to learn more about the now unavoidable Fortran 90 (which simply copied the easiest part of Ada 83), I first translated my code to F90 (not simply compiling the same code with an F90 compiler). I turned the COMMON into modules (a.k.a. package) and a type within this package, and according to the famous equation : module + type = class it resulted in an object oriented code ;-) . 1150 SLOC Time-wise, I was paying only a 20% abstraction penalty with the same compiler. Not bad. The objectification process was made in C++ at the same time. A quite painful translation indeed, but C++ was my way to earn money at that time... 1259 SLOC. Not only the translation was painful, but the compilation gave me result flawed with memory faults that I had to debug. In the end, I finally had the same accuracy as Fortran 77, but... The result looks like a good start for a flame war: C++ was 7.5 times slower than Fortran 77. With the same compiler (g++ versus g77/gfortran). I do not think it is so significant in fact, as my algorithm relies heavily on complex number, which are well integrated in Fortran, but pays the full abstraction penalty in C++... The good way to do it in C++ would be to use libraries such as Boost or Blitz. We can do it, but then do we really want to go through the hassle of extra layers? My program wasn't still parallelized, and Ada became the next candidate for the test. 1120 SLOC. The translation was swift, and when the compiler finaly let me go, the code ran (no debug needed) and was delivering the same accuracy as Fortran 77, and only a factor 2 of speed loss (compared to 7.5 for C++...). With gnat (to stay in the same compiler family). Given that complex number are not hard-embedded in Ada, they should pay the abstraction price, but they keep the price low. Later, I could capitalize on the tasks and protected objects to parallelize my program in Ada, which is as yet still not done in Fortran... But this is another story. I plan to do it in Java as well, but I expect almost the same thing as for C++: it will not be testing the strong point of the language, but really peeking at its weakest point: complex numbers. So, as far as performance is concerned, Fortran was, IN THIS CASE, the winner. Ada, was a strong contender. I will not elaborate too much on the easiness of translation: when you have worked for many month with such a short program, and converted it to 2 other languages, the 3rd translation can not be so hard. I believe that if I had to translate (or even write) other more significant codes, I would use the ability of Ada to interface with other languages: I would keep my low level routines in fast Fortran, and have the general flow of the computation driven by Ada, to make the whole picture clearer and more efficient. In between, I try to code more in Fortran 90, which is a close nephew of Ada 83. * I did the same kind of multi-language port for my education, with a quasi-random number generator, starting from a C++ version, and I have not yet found a way as elegant, and memory-wise efficient, to store an upper triangular matrix as in C++. * I also miss some syntaxic sugar of Fortran that allows to refer to line I of a matrix M as a vector with M(I, *) => If someone would like to discuss it, I will be glad to exchange on these. Best regards, Vincent PS : for language crusade, I believe that the problem of Fortran is "Fortran users", who are mostly not computer scientist. I hear the Ada fans boast "Ada doesn't make assumptions about the programmer: he can be uneducated, but the compiler will save him", but I strongly doubt the actual population of Ada coders be AS uneducated (or software-engineering-unconscious) as the actual population of Fortran coders (averaged over the last 50 years).