forums.silverfrost.com

KennyT · Joined: 02 Aug 2005 Posts: 318

While benchmarking some code (comparing some old F77 code with new improved F95 code) we noticed a severe speed impact in the new code. The below test program illustrates the issue:

JohnCampbell · Joined: 16 Feb 2006 Posts: 2615 Location: Sydney

Kenny,
It probably will not influence the result, but high_res_clock@ can sometimes produce problems. An alternative is to use QueryPerformanceCounter, which is fast and accurate as calibrated clock.

LitusSaxonicum · Posted: Tue Jul 24, 2012 8:27 pm Post subject:

Long experience tells me that compilers have what Les Hatton would have called "Safe Subsets" (he retired at the same time as me, so his web presence may not be as good as previously if you google him). He meant a subset of code elements that the majority of users could be relied upon to use correctly, most of the time. Taking it further, one can see that a compiler must have a core of facilities that users of the safe subset test and test again. These are likely to work well, and relative to comparatively newer facilities, are likely to be more optimised. In FTN95, therefore, one ought to see the FTN77 core perform rather better (reliably? faster? bug-free?) than the Fortran 90 and 95 parts, particularly anything a bit esoteric. You will see fewer bug fixes to Fortran 77 (nearly none) than to the 90/95 facilities in the published bug fix list. Indeed, apart from fixes to things that Microsoft broke wth newer Windows and Visual Studio, and a few upgraded facilities, that's about all there is.

I'm not saying that this is how it should be, only how it most likely is ...

If EOSHIFT is slow and you are the first to discover it, then it may be because no-one used it in earnest, it was fast enough for them, they never compared it to anything else and so don't know that it is slow, or they know it is slow but prefer to use a later Fortran facility rather than coding it by hand in the old-fashioned way (or something else!)

If the slowness of EOSHIFT is a show-stopper for you, then you could always try dumping the assembly language code from your Fortran 77 style version, and then using CODE ... EDOC write a faster version using more modern cpu instructions, as was done in another thread (Fortran 2003/2008) with dot products. I know several posters who would be interested in the outcome - for names, consult the thread I mentioned.

As for me, I'm an old dog, and this is a new trick that I never knew existed, much less ever imagined that I needed! (On reflection I might, but not any time soon .... MRU file lists being a case in point).

Best of luck fixing it.

Eddie

KennyT · Joined: 02 Aug 2005 Posts: 318

Les Hatton - a star! I remember a trial he did of the various seismic processing companies results. From memory, I think he defined exactly what parameters he wanted applied to a test dataset except one, which he left to the operators best judgement. When he compared the results he got back, the range of results was staggering - one set being 180degs out of phase to the others! I think he also wrote a witty article where he announced the best coloured pencils for doing seismic interpretation! Laughing

K

LitusSaxonicum · Posted: Fri Jul 27, 2012 5:10 pm Post subject:

Yes, I'm a big fan. But ALL of his articles are witty.

My safe subset of Fortran 9x is Fortran 77 - and then not all of it.

E