[m_mueller]

Given the right tools[1] you can have as much templating/macro support as in C++ while keeping everything both performant and user friendly. The key here is to wrap Fortran in script languages to make it do exactly what you want.

[1]https://github.com/muellermichel/Hybrid-Fortran (I'm the maintainer.)

[maaku]

> while keeping everything both performant

Good luck beating the performance of a Fortran optimizing compiler.

[m_mueller]

I don't really get your post. I never said that I want to 'beat' the performance of x86 Fortran. This particular framework is designed to make Fortran GPGPU compatible while not loosing any CPU performance. It was used to speed up the next generation Japanese weather physics by 3.5x (compared to six core Westmere) doing exactly that.

[maaku]

My apologies, I misread your post.

[gngeal]

Why? Any objective reason?

[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. :\