How to get the detailed optimizing information when using IFORT9.1 ?

[dshi]

Dear expert,

We are evaluating the Intel Fortran 9.1-32 version on our HSPICE product, one circuit simulating tool. We very concern the tool's floating result and runtime performance.

Afterwe used -O2 option to optimize our tool, we got some wrong results of running some cases, some floating different results of some cases, comparing with using debug version compiled by ifort.

Even if we use -mp option or -mp1 option, we still cannot get the consistent result between debug version and optimized version.

I doubt whether Intel Fortrran compiler did some wrong optimization for floating point calculation causing the different result.

I am very eager to know whether there is one way to know all of the information about compiler optimizing source files, or one way to easliy help us to diagnose which actual source lines may cause the optimizing difference.

Please notice we didn't see the similar result difference when using g77 between debug version and optimized version of -O3.

Another question, how to set optionsfor optimzing the tool to get best performance for fitting Pentium 4 and above compatible CPUs, especially Opteron and Xeon.

One more, one bug we observed that when using -xW option to optimize our tool, we got the wrong result on AMD Opteron machine, but got the correct result on Intel CPU. But it seems that the '-xW' option is recommended by Intel for fitting AMD Opteron.

Very anxious to get your help.

Deng

[invariant-invariant]

Hello,

It is a little difficult to understand your precision problems without a specific example. Our company has just now completed the transition to Intel Fortran. To avoid precision inconsistencies, we did the following:

1. Transfered all code to 64 bit double precision.
2. Compiled using /real_size:64
3. Compiled using /fpconstsant
4. Compiled using /QxN (you can also use /QxW)
5. Scanned disassemled executable for single precision calculations such as "mulps"to detect remaining single precison statements that had to be fixed.

Now our softwareis 100% double precision, only statements like "mulsd" and "mulpd" are present everywhere in the disassembled executable. When this was in place, we saw that precision problems vanished completely.

Lars Petter

[dshi]

Thank you for your suggestions.

We did the same things as what you did. We are developing our tool on Linux.

But we found when using '-mp' option (the same as /fpconsistent' on Windows, although we can get theaccurate results,the performance is much lower than that we used g77 compiled; about 30% percentage decline.

The performance and accuracy are both so important for our product. So I am looking for more suggestions and ideas here.

Deng

[invariant-invariant]

Sounds strange. What kind of program is it? Floating point intensive or memory intensive? Is it Fortran 77 or Fortran 90? How many source lines? Many independent Fortran modules? The reason I ask is that the way to compile may be dependent on the problem at hand. For example selecting optimization level/O1, /O2 or /O3 may be tricky. Sometimes /O1 is better than /O2 and /O3. Also using PGO may be beneficial. Have you tried that?

Lars Petter

[Steven_L_Intel1]

I am going to move this over to the Linux section of the forum, but I have some comments:

- Yes, we recommend -xW for current AMD processors. We'd be very interested in seeing an example program that gives different results on AMD and Intel processors. It could be that the AMD processor you are using incorrectly executes SSE2 instructions.

- In 9.1, we recommend using -"fp_model precise" instead of -mp - the performance penalty will be less.

[TimP]

I am not the only one who has been confused about whether you are discussing Windows or linux.
As the -mp and -mp1 options (Windows spelling -Op -Qprec) are deprecated (not well explained in the docs), you should prefer the -fp: options. Those may help avoid confusion between linux and Windows options. -QxW -fp:precise (linux -xW -fp-model precise) should avoid the automatic promotion of all expressions to double precision, by use of x87 instructions (SSE2 on Windows x64). This option should adhere more predictably to language standards. It prevents optimizations such as vectorized sum reduction, so as to prevent the associated numerical variations.
Beginning with the most recent 9.1 compiler, -fp:precise implies -Qftz- for IEEE gradual underflow compliance. If you don't want that, you can follow with -Qftz (linux -ftz).

[dshi]

Thanks all for your kindness, especially Steve.

First, we develops and maintainsour tool on multi platforms. Recently We are evaluating the Intel Fortran 9 compiler on Linux and Windows for planning to replace the GNU Fortran compilers to get best performance.

Our tool is one 25-year old and it's consisted of mixed languages, C/C++ about 40%, Fortran 77 source codes about 60%. Because there are about 3K Fortran source files with about 350K source lines. It's hard to diagnose which actual source file or source lines causing these issues. (Without more information generated by Compiler)

Second, I will try the -fp-model option. It seems that this option is not available on ifort 9.0 version?

Another question, I saw some articles that -xN option may be effective to better optimize source files and get better performance on Opteron machine.

I am not sure whether it will cause the same accuracy issue as -xW option.

And more whetheris the final executable file generated with -xN able to be run on these machines with different P4, Xeon and Athon-xp, Athon-64 and Opteron processors?

Deng

[TimP]

You are correct, -fp-model was available in a usable form only for C/C++ in 9.0. There are changes in its application between ifort 9.1.032 and 9.1.033. Among those changes, the combination -mp -ftz produced extremely slow code in 8.1 and 9.1.032, but this should be alleviated for those and similar -fp-model options in 9.1.033.
-xN includes a few additional optimizations beyond -xW, such as vectorization of MINVAL/MAXVAL (maybe soon also MINLOC/MAXLOC) and optimization of integer divide. However, it disallows running on AMD.

[dshi]

Where can I download the Intel Fortran 9.1.033 version?

Thanks a lot!

Deng

[Steven_L_Intel1]

If you are evaluating the compiler and signed up for support when you requested the evaluation, you can download it from Intel Premier Support File Downloads. If you did not choose to register for support at the time, go back to the Intel Registration Center, reregister your serial number and check the box to request a support account.

If you are using a non-commercial license, you will have to wait until sometime in August before obtaining 9.1.

If you have purchased a regular license, download from Intel Premier Support as above.