Clay Breshears' webinar "modernizing converted Fortran"

[TimP]

Clay presented this live last week but I didn't hear of anyone being allowed access.

New Link: https://software.seek.intel.com/SOFTWAREDEVELOPER.ModernCodeESeminarSeries.Reg?registration_source=ODnewsletter

It's apparently incompatible with Firefox but works with Chrome.  A large touchscreen would be useful if Intel doesn't correct their problem with tiny windows for these webinars.

It's a fairly typical case of an application converted from f77 to C by f2c translator, with the original Fortran discarded, with even less regard for performance or maintainability than apparently was taken with the original.  Clay retrofitted double subscripted C arrays, where f2c linearizes them.

If you weren't around in the 80's you may have missed the prevalent idea that translating from a 15 year old language to a 10 year old one would be worth untold effort.

Clay demonstrated Cilk array notation as a way to get aggressive vectorization, in preference to __restrict and #pragma simd.

He didn't explain why the usual Intel C++ default of aggressive inversion of division didn't take care of problems with division by a loop invariant (which was remarkably slow on Sandy Bridge).

[jimdempseyatthecove]

>> problem with tiny windows for these webinars.

On my Lenovo Yoga Pro laptop the presentation screen was very small, less than 1/4th the screen, and couldn't be enlarged further. Luckily for me, my desktop has a 39" 4K monitor and in which I could VNC connect to the Lenovo. The desktop doesn't have a microphone attached, and this causes problems with several of the presentation programs (dialog pops up requiring my to specify microphone).

I'd sent a private message to Clay stating my concerns about using his optimization efforts as a "test case" of why one should make the conversion (Fortran to C++). I'd asked if he had access to, or could get access to, the original Fortran source. With this he could show the effort required to modernize/optimize the Fortran source, get the runtime results, compare with the C++ optimized performance then show the time invested verses performance differences. This then would present a proper "test case" of why one should or should not consider a port or spend the time with optimization.

>>Clay demonstrated Cilk array notation ...

FWIW the acronym is CEAN: C Extensions for Array Notation, not Cilk Array Notation

>>the usual Intel C++ default of aggressive inversion of division

IMHO the compiler should never perform default of aggressive inversion of division. The user should be required to expressly present an option to request this, or to expressly use a temp in the code. Inversion and multiplication produces different results that may adversely affect conversion routines amongst other issues. Same thing with implicitly removing parenthesis. If one wants them remove, explicitly require the option. Many of the older programs were expressly written, and extensively tested with the divisions and parenthesis expressly placed. To implicitly remove these is only asking for trouble, as well as providing an excuse for the programmer to claim it wasn't his fault (when things are discovered to be going haywire).

Clay had a good presentation. It is worth a watch.

Jim Dempsey 

[TimP]

I do ordinarily set -Qprec-div -Qprec-sqrt to avoid Intel compiler replacement of division by inversion and multiplication, but this isn't satisfactory on MIC coprocessor, where there is no direct hardware support for IEEE division.  I have seen a software vendor perform detailed testing of all their opportunities for invert and multiply to see which ones might cause QA suite failures and which showed significant performance gains.

I agree with Jim about parentheses, so I always set -assume:protect_parens.  Steve Lionel seemed to agree as well, as he got protect_parens included in -standard-semantics.  gfortran has an equivalent option, which is always set to conform with standards, unless explicitly set otherwise (but gcc/g++ rejected that treatment).  It's strange that C and C++ have stricter standards than Fortran but insufficient compiler options to follow the standards in practice.

[Bernard]

@Jim, @Tim

Sorry for asking slightly off topic question.

I would like to ask you what is the best or maybe the  recommended approach to convert large code base from mixed FORTRAN 77/90 to C++ ?

I am thinking about 2 approaches:

1) Translation of FORTRAN 90 module to single C++ translation unit in its own namespace with FORTRAN subroutines converted to C++ global(namespace functions) and module globals which can be represented as a members of anonymous namespace.

2) Trying to create simple OOP design by for example converting FORTRAN subroutine into simple C++ class where subroutine's output argument(s)  can be represented as class member variable(s). One of the problem will be a large number of  some subroutine's arguments passed to it, additional problem will be issue of global variables representation in C++, but I think this can be handled by using named namespace solely dedicated to globals.

Thank you in advance.

[TimP]

Iliya,
If you didn't catch my tone, I'm not a fan of needless conversions away from Fortran.  I also have worked on projects where C++ conversion was done at the expense of performance (and with no advantages in the OOP view), even though it need not be so. It's nearly certain that performance will be lost if it's not considered.  I suppose adding some OOP features incrementally in Fortran is more practical.
The projects I've worked on probably started with little F90 and needed less skill to convert mechanically to C++.  So, trying to do such a project well is outside the realm of what I've seem.
Tim

[Bernard]

 @Tim

 I know , that you are not a fan of conversions away from Fortran and I agree with you completely, but in one case which I described here:  https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/623861      the source code exists in printed form only, so I cannot create wrappers in C++ as usually I do with very satisfactory results. 

[smith_j_]

I love springtime. I carve out time so I can plant seeds to get our garden going. Nature gets busy, and everyday life seems to pick up as well. With so much to do, we all look for ways to make life easier, more efficient, and more productive. Software development can have its fair share of menial, time-consuming tasks. I definitely want to fastforward past the tedious so there is more time for fun stuff.

[Bernard]

@smith j

So you just registered only to post your  non relevant comment?