Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!dove!dove.nist.gov!przemek From: przemek@rrdstrad.nist.gov (Przemek Klosowski) Newsgroups: comp.lang.fortran Subject: Re: NAG Fortran 90 announcement Message-ID: Date: 25 Jun 91 02:50:47 GMT References: <15634@exodus.Eng.Sun.COM> <26334@lanl.gov> Sender: news@dove.nist.gov Organization: U. Notre Dame/NIST Lines: 48 In-reply-to: jlg@cochiti.lanl.gov's message of 24 Jun 91 16:31:36 GMT >>>>> On 24 Jun 91 16:31:36 GMT, jlg@cochiti.lanl.gov (Jim Giles) said: Jim> The thing that's most disappointing about NAG's implementation is that Jim> it's a preprocessor to C. (They claim that it's a compiler because it Jim> does "global" (throughout a whole program unit) analysis, but it still Jim> outputs C as it's "object" code.) This means that those users who are Jim> the most anxious to try out the 'whole array' notation will get an very Jim> unsatisfactory comparison because of the pessimizing effect of C on Jim> array (in C: pointers) calculations. I understand that Jim is known for his dislike of UNIX and C, so I suppose that I shouldn't be surprised by his criticism. However, I have to object to his claim that C is pessimizing the array calculations. Au contraire, it is well known that some of the optimizations used to treat multidimensional arrays in Fortran are much easier expressed in C---strength reduction in index calculations, for example, is naturally expressed in C by having a pointer to the column (row in C, actually). As far as I can tell, Fortran could only do it by static (compile time) equivalence. About translation vs. compilation in general, I believe that the distinction nowadays became moot. Most of the compilers are multipass, and use multiple intermediate representations: RTL, ucode, assembler, and yes, why not C. The bottom line is the speed of the program (usually not very dependent on the language) and speed of compilation (admittedly smaller for compilers using many intermediate phases). As to the former, let me tell you about my own experience: my friend had a hydrodynamics code in Fortran (many array accesses!). I have heard rumors that people observed speedups on their fortran code by translating to C (using f2c). I tried f2c; the result was that the C code after the automatic translation was 10% slower. I could easily tune it (avoiding unnecessary intrinsics argument conversion etc), but the point was that both Fortran and C code was spending time in the same places! I am afraid that with the current compiler technology it doesn't matter much. The algorithms DO matter, however, and C seems to be better in allowing for more complicated data structures etc. In the case of my friend's code, a lot of time was spent in calculating distances between particles. Many of these calculations were unnecessary because the particles were far apart. If I were writing in C, I would venture to create linked lists of particle clusters, "topologically" limiting the interactions to clusters of particles that are known to lie close to each other (a la Jon Bentley). I do not know of a good way of expressing such things in Fortran (flameproof suit on) przemek -- przemek klosowski (przemek@ndcvx.cc.nd.edu) Physics Department University of Notre Dame IN 46556