Fortran Powerstation and Intel Visual Fortran

[bendel_boy]

We are porting an old Fortran PowerStation program. However, the original on a test problem runs in c. 4 seconds. WIth all optimisations on, on the same PC, Intel Fortran 9.1 takes 7 - 9 seconds. The data file as created years ago and is compatible with FPS 4.0; consequently we are using the relevant compatibility options with IVF.

The end user claims that with a full dataset the runs may take hours, so is unhappy that the new compiler has produced a large slow-down. The timing code I have moved so that it I believe it starts after all datafiles have been read. Does anyone have any suggestions as to why IVF would be so much slower? I've tried DVF 6.1, and that was also slower, and similar in speed to IVF. All are running as console applications, al timed from a command prompt.

(My profile doesn ot allow new posts, hence I'm apending to an old one with at least a similar title!)

[Steven_L_Intel1]

(I've split this off to it's own thread and will investigate why you could not post separately - never heard that one before.)

Without seeing the application, it's hard to guess what the problem might be. However, I have seen one thing consistently trip up people here and I suggest it to you. Set the option /assume:byterecl (in Visual Studio, this is Data > Use Bytes as RECL=Unit for Unformatted Files. What happens is that the program opens an unformatted file with an explicit RECL= value, which in PowerStation was in units of bytes but in CVF (and Intel Fortran) is in 4-byte units. Files written then write four times as much data as they should, and this is slower.

When you say "all optimizations on" - exactly what are the settings? You can copy them from the "Command Line" property page in Visual Studio.

[bendel_boy]

I asked the user to try the program on a larger example, in case the degradation in performance was not as marked as she had feared. With that larger problem she reported that the IVF code was faster - c. 110 seconds (IVF) to 120 seconds (MPS). So she's happy, and has taken over the code & project.

By 'all optimisations on' I meant that I within the options available in VS.NET 2003 as the IDE I went through & selected the highest level of optimisations available to me, given that I am using an AMD Sempron & she is using something of lower spec - I don't know quite what.

As an aside, the original code is badly written - we had two 'show stoppers' with array-out-of-bounds exception; the first I could readily code around (it was writing to index 0 when the lower bound was 1), the second would have required time to investigate (but was reading from index 2 when the upper bound was 1); so we switched off further bound checking, and I warned that the code risked producing invalid answers. It has been in use since the 1980s and has been regarded as accurate & 'adequately robust.'

[Steven_L_Intel1]

Glad to hear it. I have encountered many programs "regarded as accurate and robust" over the years with coding errors caught by newer compilers. The second array bounds issue surprises me as with an array declared as (1) the compiler disables bounds checking as this was a popular way of coding the equivalent if (*) before Fortran 77.

[bendel_boy]

The array was passed as INTEGER IARR(NARR), where NARR happened to have the value 1.