[dmlorenzetti]

One thing that for years made Fortran stand out is that the language explicitly assumes all arrays passed in to a subprogram have no overlaps.

Thus a Fortran compiler doesn't have to do anything special to make sure it preserves order when storing and accessing from two different arrays. Therefore the compiler can be much more aggressive about unrolling loops and changing the order of operations.

By contrast, given a loop like

  for( i=0; i<N; ++i ) {
    y[i] = 2*x[i];
    }

a C compiler has to assume that y[i] might be the same memory location as x[i+1], for example. Thus it has to ensure that the load into y[i] is complete before accessing x[i].

This is one reason you see a lot of C code that does numerical work hand-unrolled, with explicit stores, like this:

  for( i=0; i<N; i+=4 ) {
    xi = x[i];
    xip1 = x[i+1]; xip2 = x[i+2]; xip3 = x[i+3];
    y[i] = 2*xi; ... y[i+3] = 2*xip3;
    }

Now that C provides the "restrict" keyword, a smart C compiler can do many of the same optimization tricks that Fortran has had since day 1.

[gngeal]

One thing that for years made Fortran stand out is that the language explicitly assumes all arrays passed in to a subprogram have no overlaps.

There's a HUGE number of languages that don't allow aliasing in this way. I wasn't thinking about "how to improve C", I had APL, J, K, Q etc. in mind, as well as languages that implement mass array processing with similar semantics in terms of a more conventional syntax.

[dmlorenzetti]

Fundamentally I agree with you. In my original comment, I was just trying to give a historical view of why people took the view that "optimizing Fortran compilers are hard to beat," rather than to defend it.

Personally, I think that idea is hard to justify these days, especially when, in my experience, finding 20-30% speed differences between optimizing Fortran compilers isn't all that hard.

[coolsunglasses]

That's a compiler flag in C and has been for ages. :\