hirchert@ux1.cso.uiuc.edu (01/24/90)
Sean Eric Fagan (seanf@sco.COM) writes: >In article <14199@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes: >>This is a particularly bad example for you to use. The optimization >>that you want the compiler to do without is called "common subexpression >>elimination". It is important that your compiler know how to do this >>optimization even if you do have a '+=' operator. I wouldn't ever buy >>a compiler which didn't have this capability. A compiler without this >>capability is somewhat behind the state-of-the-art anyway (by about 30 >>years). > > x[i] = x[i] + foo(); > >vs. > > x[i] += foo(); > >where one or more of x and i are global. Oops. If your FORTRAN copmiler >optimizes that away, you quite probably, have some problems. Not in FORTRAN; the function reference foo() is prohibited from altering anything referenced in the same statement, so it doesn't matter whether x and i are global or not -- a FORTRAN compiler can do the optimization. FORTRAN has been described as "the only language in which all the classic optimization techniques work". This is just another example. Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications
hirchert@ux1.cso.uiuc.edu (01/24/90)
brnstnd@stealth.acf.nyu.edu writes: >The only problem with aliasing is parallel optimization. Not true. There are many sequential, scalar optimizations that are inhibited by aliasing, including common subexpression elimination, removal of loop invariants, strength reduction, and some forms of peephole instruction scheduling. In fact, there are few forms of optimization that aren't inhibited by aliasing. Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications
hirchert@ux1.cso.uiuc.edu (01/25/90)
brnstnd@stealth.acf.nyu.edu writes: >Normal Fortran has only two advantages over C, namely a wider set of >standard builtins and a larger support base. Fortran 90 loses the >support base (why did X3J3 have to change the comparison names?) and >adds just two other advantages: named loops and the multilevel break. >Other articles list many of the advantages of C over Fortran. X3J3 didn't change the comparison names. It added symbolic synonyms. This means you are allowed to write something like IF (X<Y) THEN but your existing code that says IF (X.LT.Y) THEN will work, too. In general, a standard-conforming Fortran 90 compiler should also be a standard-conforming FORTRAN 77 compiler, so the existing base of code should port to Fortran 90 with no difficulties other than those one can expect going to a new FORTRAN 77 compiler. Eventually, there will parts of the existing support base that one will want upgrade to take advantage of new features in Fortran 90 (e.g., allocating work arrays directly rather than requiring them to be passed in), but the existing support base should remain available until that happens -- evolution rather than revolution. For much of the community that uses Fortran, the important advantage that Fortran has over C is superior performance, a reflection of both more mature optimization technology and of the greater inherent opportunities for optimization in Fortran. Presumably, C optimization technology will eventually be as mature as that used in Fortran compilers, but the only way to catch up on optimization opportunities is to add declarations or directives to assert those conditions that are inherently asserted in Fortran. Please note that I am not asserting that Fortran is a better language than C, only that there is a class of problems for which Fortran is better suited than C. (There is also a range of programs for which C is better suited and several classes of problems for which neither language is particularly well suited.) If you program in C and are happy, that's fine with me. Just don't assume I am stupid because I recognize that there are benefits in continuing to program part of my work in Fortran. Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications
hirchert@ux1.cso.uiuc.edu (01/25/90)
Wayne Faustus (faustus@yew.Berkeley.EDU) asks: >I haven't used FORTRAN myself, but from these discussions it seems >to me that there are a lot of things you are not supposed to do to >make things nice for the compiler, like create aliases and allow foo() >in "x[i] + foo()" to alter x or i. Do FORTRAN compilers check these >constraints? If not, aren't they a great source of hard-to-find bugs, >that go away when you turn off optimization? For the most part, Fortran compilers do not check these constraints, so violations can be bugs that are hard to find, but Fortran programmers tend to program in ways that avoid many of these mistakes, and some are easier to find than you might realize. For example, many Fortran programmers follow the convention that functions should be free of side effects and that a subroutine should be used when side effects are desired. Those that do write functions with side effects are extremely careful about affecting other expressions or subexpressions in the same statement because there has never been any guarantee on the order in which these expressions are evaluated, so such a program would be likely not to behave correctly when ported to a new machine or compiler. The aliasing problems show up also in different variations of copy-in/copy-out argument association, independent of optimization level, so a program might have undetected aliasing problems on the first machine it is written on, but such problems are usually detected as it is ported to other machines using other argument association implementations. Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications
hirchert@ux1.cso.uiuc.edu (01/25/90)
Sean Eric Fagan (seanf@sco.COM) writes >In article <14203@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes: >>This is not true. There is _NO_ case that I'm aware of that parenthesis >>are _REQUIRED_ in Fortran (ADA, Pascal, etc.) when they are not also >>_REQUIRED_ in C - and with the _SAME_ consequences with respect to >>optimization. It is with _OPTIONAL_ parenthesis that the languages >>differ. In C, the compiler ignores them, in all the other languages >>the compiler must evaluate in parenthesis order. So, the trade-off you >>mention is under direct user control in all languages but C. > >1. Given > a + b + c - e - f; > >I'm happy to let the compiler rearrange things as much as possible to >generate fast code. In FORTRAN, by your own admission, you can't do that. I don't see him admitting this. In the absence of parentheses, a Fortran processor is free to choose any mathematically equivalent evaluation order (even though this might produce different results in the machine arithmetic). > >2. Given > > ((((a + b) + c ) -e ) - f); > >The compiler is free to rewrite this, *IFF* the result would be the same! >If you're using shorts, and overflows are ignored, then, probably, it can do >what it wants to. If, however, the result is *not* the same, then the >compiler cannot do this, and, if it does, it's a bug. Although the Fortran standard is less explicit about this, Fortran processors are also allowed transformations that don't change the machine results. Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications