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,c4cb2c432feebd9d X-Google-Thread: 1094ba,c4cb2c432feebd9d X-Google-Attributes: gid103376,gid1094ba,public X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news4.google.com!newsfeed.stanford.edu!shelby.stanford.edu!not-for-mail From: Brooks Moses Newsgroups: comp.lang.ada,comp.lang.fortran Subject: Re: Ada vs Fortran for scientific applications Date: Mon, 22 May 2006 11:49:58 -0700 Organization: Stanford University Message-ID: <447207D6.3010408@cits1.stanford.edu> References: <44715DED.5050906@cits1.stanford.edu> <4dd87pF18ot14U1@individual.net> NNTP-Posting-Host: dnab42a5dc.stanford.edu Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Trace: news.Stanford.EDU 1148323806 4022 171.66.165.220 (22 May 2006 18:50:06 GMT) X-Complaints-To: news@news.stanford.edu User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en In-Reply-To: <4dd87pF18ot14U1@individual.net> Xref: g2news2.google.com comp.lang.ada:4347 comp.lang.fortran:10091 Date: 2006-05-22T11:49:58-07:00 List-Id: Jan Vorbr�ggen wrote: >>Now, it is highly unlikely that the Ada language has anything in it that >>will cause more than a few percentage points of difference in the >>maximum theoretically-achievable speed. Thus, in practice any speed >>differences are going to be almost entirely a factor of the quality of >>the code you write, and the quality of the compiler you compile it on. > > That might be the case for Ada, but it's not clearly true for others. > > A language - any language, but in particular a computer or programming > language - has both syntax and semantics. In trying to evaluate a language, > people too often only look at the syntax - how can I express an operation > I want executed? - instead of primarily the semantics - what in detail does > "operation" mean here? -. If a language does not allow you to express cer- > tain things that you know to be true about your operation, and that could > be used to optimize the program, you are already at a disadvantage compared > to a different language where that is not the case. As an example, look at > the semantics of a DO loop and the apparantly equivalent FORALL statement > in Fortran. I agree, in principle -- and you've stated it rather more clearly that I was able to; much of that is something that I meant to say and didn't really. My contention is that, in practice, most of the languages that numerical code is commonly written in have semantics that are sufficient to do the task reasonably well. And that as such, once one passes a certain bar of functionality for the task, semantics have rather little impact on the decision -- things like the distinction between a DO loop and an equivalent FORALL construct rarely seem to have a significant impact. (This does, though, require that one get past that bar, and a lot of languages don't, usually because that's not what they're intended for.) I should note, though, that I'm drawing the syntax/semantics line way over on the side of semantics. For instance, I consider complex arithmetic and multidimensional arrays to be essentially syntax -- one can trivially write code longhand to produce the same functionality. It's just awfully inefficient syntax. On the other hand, I suspect that my view is colored pretty heavily from not having a lot of parallel-processing experience, and that semantics aren't anywhere near a most-of-the-top-languages-are-equivalent ceiling there. Thus, I should probably limit my above claims to single-threaded programs -- which I recognize is a significant limitation. - Brooks -- The "bmoses-nospam" address is valid; no unmunging needed.