24
$\begingroup$

I will start with my personal experience in our lab. Back in the ifort 9 and 10 days, we used to be quite aggressive with the optimizations, compiling with -O3 and processor specific flags (-xW -xSSE4.2 for example). But starting with ifort 11, we started to notice:
1. some inconsistencies in the results (because semantics were not preserved)
2. smaller gains compared to -O2.

So currently, we usually simply compile with -O2 and -xhost. Do you have better suggestions with ifort 11? Will this change once again as we transition to ifort 12? Thanks in advance.

$\endgroup$
3
  • 9
    $\begingroup$ Optimizations do not benefit all codes uniformly. Thus, I think a better question would be "How could I profile my code in order to tell what compiler optimizations are effective?" $\endgroup$ Commented Dec 7, 2011 at 11:23
  • 1
    $\begingroup$ Because semantics were not preserved, or because something was reordered? This may be wandering a bit from the topic, but it would be good to see a snippet of code that reproduces the problem. It may be that something was reordered in a way that you don't like but that the compiler thinks should be fine. My experience is that Intel 12 does a better job of vectorization than any of its predecessors, so I would expect more changes to be coming when you switch to the latest. $\endgroup$
    – Bill Barth
    Commented Dec 7, 2011 at 13:35
  • $\begingroup$ I thought saying semantics were not preserved was equivalent to ordering was not preserved. Anyway, I realize my question is (too?) generic, and I didn't want to dwell in specifics. We have had several problems with intel 10, some were compiler bugs and some were left unexplained. So with 11, we've been playing it safe and we've been happy with the performance. But maybe we are playing it too safe, and I wanted to know if the community had some advice. $\endgroup$ Commented Dec 7, 2011 at 15:41

3 Answers 3

19
$\begingroup$

We strongly recommend all our users start with -O3 -xHost -ipo for both ifort 11 and ifort 12. If there are particular floating point transformations enabled by O3 that affect the precision of some of your computations, you can turn those specifically off with -fp-model precise -fp-model except (or, more drastically, -fp-model strict) while retaining the other optimizations O3 enables, such as loop blocking for cache, loop fusion and unrolling, and memory access optimizations.

I'd advise trying the floating point model stuff on individual files and finding out where it makes a difference, rather than turning it off globally; it can be a ~15% speed bump, and you want to be able to keep that where it doesn't affect your calculations. If you're not sure where the precision is being affected, you can play with turning on and off the floating point model flags for those files, or playing with rounding modes.

We recently gave a short talk to our users about optimization flags, focusing on the GNU and Intel compilers for x86; you can see the slides from that talk here.

Incidentally, while we're talking about choosing optimization flags for your code, every now and then it's also worth looking at the output of a vectorization report to see where the compiler attempted to vectorize a loop and couldn't. Sometimes there are small changes you can make to your loop which can result in vectorization being possible (which can be a 4x speedup). Similarly, see -qopt-report for information on more general optimization reporting (-opt-report, for older versions).

$\endgroup$
2
  • $\begingroup$ I like your answer but I've tried it again with one of our testcase and -O3 -xhost -fp-model precise -fp-model except resulted in a 30% slowdown. I'll look again at the profiling and the -vec-report to try to see what's going on... $\endgroup$ Commented Dec 17, 2011 at 18:57
  • 2
    $\begingroup$ Over -O2 -xhost? That's interesting; it's very unusual but it can happen. In cases like this, the optimizer is doing something that it has good reason to think will improve the speed, but it turns out makes things worse. Usually for scientific code, which has fairly straightforward structure, that doesn't happen. In cases like this, Profile Guided Optimization - software.intel.com/sites/products/documentation/hpc/compilerpro/… - can often help. $\endgroup$
    – user389
    Commented Dec 17, 2011 at 19:00
6
$\begingroup$

I work for a company that produces large, highly technical applications in Fortran with IFort - the applications are very performance critical, since the speed (while maintaining accuracy) is the main selling point.

We always compile with -O3, and to my knowledge, the main things that -O3 do are loop unrolling and prefetching. I suspect that most scientific computing applications benefit greatly from these, in particular the loop optimizations. We haven't seen compiler errors in quite some time (though we've seen a few linker errors when using Ifort on a Mac). We use 11.1.095.

I hope this helps.

$\endgroup$
5
$\begingroup$

I realize this answer is probably far, far too late, but for aggressive optimization, the "-fast" option seems like the easiest solution. Excerpts from the man page:

-fast
    Maximizes speed across the entire program.
    Description:
    This option maximizes speed across the entire program.

    It sets the following options:
     - On Linux* systems: -ipo, -O3, -no-prec-div, -static, and -xHost
     - On OS X* systems: -ipo, -mdynamic-no-pic, -O3, -no-prec-div, and -xHost
     - On Windows*  systems:  /O3,  /Qipo,  /Qprec-div-,  and /QxHost

    NOTE: Option fast sets some aggressive optimizations that may not be appropriate for all
    applications. The resulting executable may not run on processor types different from the
    one on which you compile. You should make sure that you understand the individual optimi-
    zation options that are enabled by option fast.
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.