> -----Original Message----- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER- > [email protected]] On Behalf Of Glen > Sent: 25 January 2018 08:02 > To: [email protected] > Subject: Re: Fair comparison C vs HLASM > > (snip on optimizing and compilers) > > > > On January 24, 2018 at 8:54 PM Paul Raulerson wrote: > > > > Of course, the C compiler took this: > > > > #include > > > > int main(int argc, char *argv[]) { > > int c=0; > > int x=0; > > > > for (x=0; x< 100000000; x++) { c++; } > > > > printf ("\nThe final value is [%d]\n", c); } > > > > > > and optimized it during compile time. > > > > In fact it optimized it so much it simply generated a LHI of a > > register with 100000000 in it. (grin) Needless to say, it ran somewhat > > faster than my friend’s program. Even counting the screen print. :) > > ite: http://www.gkc.org.uk/gkc | Erdos number: 4 > > There is a story from the OS/360 days of a popular Fortran benchmark > that evaluated > complicated math functions and such, all done using statement functions. > > It seems that Fortran H expands statement functions inline, and also > does constant evaluation > at compile time. > > As in the above example, the compiler evaluated the whole thing at > compile time > (very slowly) and at run time printed out the precomputed value (fast). > > If Fortran H could do it 40 years ago, C compilers should do it today. > (But I don't know that Fortran H did loop evaluation.)
I don't know if Fortran H does loop unrolling, but some compilers that are targeted at Vector Processors do. FORTRAN can be a pig of a language though, especially with a poor compiler. Even worse, on two dimensional arrays, the data is stored as columns, not rows. (I think that’s correct. So if you vary the last subscript, you leap all over storage. Typically Fortran users want to write code where the last subscript varies fastest resulting in excessive paging. Reversing the subscript order in such programs can produce a significant performance improvements. > > -- glen Dave
