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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,d901a50a5adfec3c X-Google-Attributes: gid103376,public From: gisle@lunde.ii.uib.no (Gisle S{lensminde) Subject: Re: Fortran or Ada? Date: 1998/09/23 Message-ID: <6uboki$8qh$2@toralf.uib.no>#1/1 X-Deja-AN: 394135223 Content-Transfer-Encoding: 8bit References: <98092310454016@psavax.pwfl.com> Content-Type: text/plain; charset=iso-8859-1 Organization: University of Bergen, Norway Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-09-23T00:00:00+00:00 List-Id: In article <98092310454016@psavax.pwfl.com>, Marin David Condic, 561.796.8997, M/S 731-96 wrote: >Gisle S{lensminde writes: >>But if we write comparable code in both languages, I would think that >>Fortran would win in a raw speed test, because some of the Fortran >>compilers optimize extremly well. >> > If you have not already heard from the compiler writers in the > crowd, I'm sure you will. You can't really compare "The Speed Of > Ada" to "The Speed Of Fortran" because it isn't the language that > makes it fast, it's the implementation. I have seen some really > crappy code generation done for Ada and I have seen code > generation that is every bit as tight as anything you can get out > of Fortran. As long as you are comparing similar features (say, > basic arithmetic operations, or looping or branching, etc.) I > think you'll find that there is no reason why the Ada won't > compile down as tightly as similar statements in Fortran. > And I said earlier that a fair comparision is difficult. It is also almost right that the speed of "comparable" code doesn't have anything with the language to do. But the my experience is that very few arcitectures have an Ada compiler that for "comparable" code produces faster code, even if you turn off the checks, and there are probably several reasons for this. The Fortran compiler writers have a smaller language to optimize for, and there are more literature on optimization in Fortran than in any other language. Even many of these methods can be aplied in Other langages, even the existence of a feature in a language, can do a code transformation useless. An example of this is the aliasing ( &variable ) in C. Because all variables can be pointed to, it is much harder to "optimize away" a variable. Ada is not as bad as C in this respect, and the strong typing should in fact make some optimization tecniques easier, but the total effort spent to make good Ada compilers is far less then the effort of making good Fortran compilers. But.... Engineers and scientist are often very conservative in respect of language choice. They use Fortran 77, and they are not willing to learn anything else. In a software engineering perspective this is often bad, and much of the Fortran code I have seen is badly written and nearly impossible to maintain, so speed is definitly not the only issue. Ada gives the possibility to get some software engineering into the organization, and get better code quality. Then the programmers can spend there time on new features, and not on debuging. The problem is that a conversion to Ada is very hard many places, and f90/95 is an improvment over f77. A combinition of Ada and Fortran is a possibility, since the interfacing is quite good, but the hard part is to get anyone convinced about that. > Oh, sure, if you leave in checks that Fortran doesn't perform, > you'll see Ada code that is slower. But I don't know of any Ada > compilers where you can't disable those checks and run without the > safety net if speed is an issue. (We do it regularly around here > for our real time control systems.) Also, I've heard tell of > Fortran compilers that included support for specialized hardware > (the Cray comes to mind) where they could generate extremely fast > code to, say, multiply vectors and such. But that's a little like > cheating since you are talking about a customized compiler for a > very narrow niche. One could do the same with an Ada compiler, but > you'd have to be spending the money to build it for the same niche > and that might not make economic sense. > > We regularly build hard, real time systems with Ada and are almost > always evaluating some kind of compiler technology. We have yet to > see the case made that "Language X" can't be compiled as tightly > as "Language Y" provided that both languages implement similar > features so that we are comparing apples and apples. (O.K., there > *is* Befunge, which is a language beyond the bounds of sanity. So > maybe I speak too strongly... ;-) > Is there a welldefined bound of sanity? :-)} -- ------------------------------------------------------------------------ Gisle S�lensminde Tlf: 55 34 07 63 Eliasmarken 16 5031 Laksev�g epost: gisle@ii.uib.no UNIX is user friendly. It's just selective about who its friends are. ------------------------------------------------------------------------