Advanced Compiler Options for Performance

Performance libraries

There are several libraries that can help performance, including:

1. The optimized math library, selected by the switch -xlibmopt in Fortran and C++, or by including -lmopt in C. This library may produce slightly different results, usually differing only in the last bit, in order to achieve higher performance.
2. There are various memory allocation libraries that can be used. A guide to several choices can be found in the NOTES section of the umem_alloc(3MALLOC) man page. In addition, the library libfast.a is available. Like libbsdmalloc, libfast keeps free lists of various sizes to provide very fast allocation, but at the expense of additional memory. Also, libfast samples the allocation stream and will create a new free list if consecutive samples are sufficiently smaller than the current free list size. The libfast library will be used when -lfast is added to C, Fortran, or C++ compile flags for single-threaded applications. For threaded applications (for example, those compiled with -xautopar, -xopenmp or -mt) then the reentrant version -lfast_r is required. The libfast library is available on Oracle Solaris SPARC and x86 platforms in -m32 and -m64 formats. There is no Linux version available at this time.
3. The Sun Performance Library, which is a set of optimized, high-speed mathematical subroutines that are used to solve linear algebra and other numerically intensive problems. The library is linked to your application by using the switch -xlic_lib=sunperf.

   Note: The optimized math library, sunperf, and several other math libraries are described in the Numerical Computation Guide.

4. An optimized memset/memcpy library, suitable for UltraSPARC-III or later systems. To use it, add the switch -ll2amm to your compile command. You might also need to add -xarch=v8plusb to your command line. Note that compiling with -ll2amm produces a binary that cannot be used on previous generation processors.

5. The Apache C++ Library, also referenced as stdcxx. This library is available on Oracle Solaris 10 8/11 (Update 10) and later, and on Oracle Solaris 11. The library may not be installed by default on a supported system. If it is missing, install it from the appropriate Oracle Solaris repository.

   If the library is installed, select the library by using the option -library=stdcxx4 on every CC command, compiling and linking, as described in the C++ Users Guide, chapter 12.

   If you cannot upgrade to a version of Oracle Solaris that supports Apache stdcxx.

   (Note: Do not use the version found at apache.org. It will not work on Oracle Solaris.) You do not need to build the entire "userland" gate, you can build just libstdcxx and install it and the associated header files.

   Support for stdcxx varies depending on whether you are using a copy pre-installed with Oracle Solaris, or a copy you have built yourself:

   1. If you are using a copy of stdcxx that comes pre-installed with Oracle Solaris, bug reports will be accepted on the library itself, and will be addressed. It is possible that Oracle may choose to modify the library in order to resolve a support issue.
   2. If you have built your own copy, then support requests should demonstrate that the compiler or runtime environment is incorrectly interacting with stdcxx, and the compiler team will attempt to improve such interaction, but obviously will not modify your copy of the stdcxx source code. The team can also point out incorrect or unportable constructs in stdcxx if that is the reason for the failure.

Compiler Component Options

The Oracle Solaris Studio compilers are divided into several different components. Sometimes, it can be helpful to performance if switches (see the cc -W option for example) are sent directly to individual components, including:

• CC, driver for C++
• cg, the code generator
• d, driver for C
• f90comp, front end for Fortran
• iropt, the global optimizer
• ld, the link editor
• ube, the x86/x64 code generator
• ube_ipa, the x86/x64 interprocedural optimizer

NOTE: although the use of these options are supported, there are certain notes that must be understood before using them.

• Usually, these options are set automatically:

  Usually, the compiler itself picks values for these options, based on other options that are selected. Most users will achieve adequate performance without needing to set these options.

• Subject to change:

  These options may change from release to release of the compiler. The spelling, effect, and even presence of these performance options may evolve from time to time; Makefile authors should be prepared to cope with such evolution.

• Performance testing is required:

  Some of these options may help your code run faster; others might actually make it run more slowly. You should not use one of these options unless you believe that you have a good test case to demonstrate its effect. A good test case:

  • represents an important real-life use of the code;
  • can be compiled both with and without the compiler option in question;
  • includes a repeatable workload; and
  • has available a machine environment where changes can be reliably measured.

• Understand what the driver is doing:

  If you choose to experiment with the options documented on this page, you will probably find it useful to examine what the compiler driver is passing to each stage of the compilation, both before and after your changes. You can do this by adding -v to your Fortran or C++ compile, or by adding -# to your C compile. For example, if you wanted to check whether the driver passes -Aheap to iropt, you could find out by typing (in a C shell) something like this:

  
   % cc -# -fast -W2,-Aheap tmp.c |& grep bin/iropt | fold -s -20 | \ 
  grep Aheap -O5 -Aheap 
  % 
  
  

  The above command pipes stderr to grep, which looks for the line that invokes iropt. Since that line is very long, we fold it into smaller chunks, and then examine the chunks for one containing " Aheap".

• Correctness testing is recommended:

  The use of performance options may sometimes lead to unexpected results. For example, a program may have a bug whichis harmless when compiled without optimization, but which causes incorrect operation when the compiler uses more advanced optimizations. In addition, although these options have been tested by Oracle internally, they have had less exposure to customer applications.

  Therefore, as in any other performance improvement exercise, it is prudent to include testing for correct output as you tune performance.

Below is a selected list of options that can be passed directly to Oracle Solaris Studio compiler components. These are passed using the -W flag (when using the C compiler) and the -Qoption flag (when using the Fortran or C++ compilers). The table below shows the relationship between the C and Fortran/C++ compilers and how to invoke the options. The f90comp component is Fortran specific and not available from the C or C++ compiler. The ld component is not needed from the C or C++ compiler, just use the -M flag.

As an example, the following shows how the compile line would look to invoke the -Abopt option to the iropt component of the compiler when compiling a program for C, Fortran and C++.

cc -W2,-Abopt c_example.c 
f95 -Qoption iropt -Abopt fortran_example.f95 
CC -Qoption iropt -Abopt cxx_example.cxx 

The "Component" column below is the name of the compiler component as specified for the Fortran and C++ compilers. The "Option" column is the action requested of the specific compiler component. The "Description" column describes what the option does.