This chapter includes the following topics:
This chapter provides an overview of the SGI compiling environment on the SGI family of servers.
Tuning an application involves making your program run its fastest on the available hardware. The first step is to make your program run as efficiently as possible on a single processor system and then consider ways to use parallel processing.
Virtual memory (VM), also known as virtual addressing, divides a system's relatively small amount of physical memory among the potentially larger amount of logical processes in a program. It does this by dividing physical memory into pages, and then allocating pages to processes as the pages are needed.
A page is the smallest unit of system memory allocation. Pages are added to a process when either a page fault occurs or an allocation request is issued. Process size is measured in pages, and two sizes are associated with every process: the total size and the resident set size (RSS). The number of pages being used by a process and the process size can be determined by using the pmap(1) command or by examining the contents of the proc/ pid/status directory.
Swap space is used for temporarily saving parts of a program when there is not enough physical memory. The swap space may be on the system drive, on an optional drive, or allocated to a particular file in a filesystem. To avoid swapping, try not to overburden memory. Lack of adequate memory limits the number and the size of applications that can run simultaneously on the system, and it can limit system performance. Access time to disk is orders of magnitude slower than access to random access memory (RAM). Performance is seriously affected when a system runs out of memory and uses swap-to-disk while running a program. Swapping becomes a major bottleneck. Be sure your system is configured with enough memory to run your applications.
Linux is a demand paging operating system, using a least-recently-used paging algorithm. Pages are mapped into physical memory when first referenced, and pages are brought back into memory if swapped out. In a system that uses demand paging, the operating system copies a disk page into physical memory only if an attempt is made to access it. That is, a page fault occurs. A page fault handler algorithm does the necessary action. For more information, see the mmap(2) man page.
You can obtain an Intel Fortran compiler or an Intel C/C++ compiler from Intel Corporation or from SGI. For more information, see one of the following links:
In addition, the GNU Fortran and C compilers are available on SGI systems.
For example, the following is the general format for the Fortran compiler command line:
% ifort [options] filename.extension |
An appropriate filename extension is required for each compiler, according to the programming language used (Fortran, C, C++, or FORTRAN 77).
Some common compiler options are:
-o filename: renames the output to filename.
-g: produces additional symbol information for debugging.
-O[level]: invokes the compiler at different optimization levels, from 0 to 3.
-ldirectory_name: looks for include files in directory_name .
-c: compiles without invoking the linker. This option produces an a.o file only.
Many processors do not handle denormalized arithmetic (for gradual underflow) in hardware. The support of gradual underflow is implementation-dependent. Use the -ftz option with the Intel compilers to force-flush denormalized results to zero.
Note that frequent gradual underflow arithmetic in a program causes the program to run very slowly, consuming large amounts of system time. You can use the time(1) command to determine the amount of system time consumed. In this case, it is best to trace the source of the underflows and fix the code; gradual underflow is often a source of reduced accuracy anyway. prctl(1) allows you to query or control certain process behavior. In a program, prctl tracks the location of floating-point errors.
A module modifies a user's environment dynamically. A user can load a module, rather than change environment variables, in order to access different versions of the compilers, loaders, libraries, and utilities that are installed on the system.
Modules can be used in the SGI compiling environment to customize the environment. If the use of Modules is not available on your system, its installation and use is highly recommended.
To retrieve a list of Modules that are available on your system, use the following command:
% module avail |
To load Modules into your environment, use the following commands:
% module load intel-compilers-latest mpt/2.12 |
 | Note: The preceding commands are an example only. The actual release numbers vary depending on the version of the software you are using. See the release notes that are distributed with your system for the pertinent release version numbers. |
The following command displays a list of all arguments accepted:
sys:~> module help
Modules Release 3.1.6 (Copyright GNU GPL v2 1991):
Available Commands and Usage:
+ add|load modulefile [modulefile ...]
+ rm|unload modulefile [modulefile ...]
+ switch|swap modulefile1 modulefile2
+ display|show modulefile [modulefile ...]
+ avail [modulefile [modulefile ...]]
+ use [-a|--append] dir [dir ...]
+ unuse dir [dir ...]
+ update
+ purge
+ list
+ clear
+ help [modulefile [modulefile ...]]
+ whatis [modulefile [modulefile ...]]
+ apropos|keyword string
+ initadd modulefile [modulefile ...]
+ initprepend modulefile [modulefile ...]
+ initrm modulefile [modulefile ...]
+ initswitch modulefile1 modulefile2
+ initlist
+ initclear |
For details about using Modules, see the module(1) man page.
Libraries are files that contain one or more object (.o) files. Libraries simplify local software development by hiding compilation details. Libraries are sometimes also called archives.
The SGI compiling environment contains several types of libraries. The following topics provide an overview about each library:
Static libraries are used when calls to the library components are satisfied at link time by copying text from the library into the executable. To create a static library, use ar(1) or an archiver command.
To use a static library, include the library name on the compiler's command line. If the library is not in a standard library directory, use the -L option to specify the directory and the -l option to specify the library filename.
To build an appplication to have all static versions of standard libraries in the application binary, use the -static option on the compiler command line.
Dynamic libraries are linked into the program at run time. When you load dynamic libraries into memory, they are available for access by multiple programs. Dynamic libraries are formed by creating a Dynamic Shared Object (DSO).
Use the link editor command, ld(1), to create a dynamic library from a series of object files or to create a DSO from an existing static library.
To use a dynamic library, include the library on the compiler's command line. If the dynamic library is not in one of the standard library directories, use the -L path and -l library_shortname compiler options during linking. You must also set the LD_LIBRARY_PATH environment variable to the directory where the library is stored before running the executable.
The Intel compiler provides the following C/C++ libraries:
libguide.a and libguide.so , which support OpenMP-based programs.
libsvml.a, which is the short vector math library.
libirc.a, which includes Intel support for Profile-Guided Optimizations (PGO) and CPU dispatch.
libimf.a and libimf.so, which are Intel's math libraries.
libcprts.a and libcprts.so , which are the Dinkumware C++ libraries.
libunwind.a and libunwind.so , which are the Unwinder libraries.
libcxa.a and libcxa.so, which provide Intel run-time support for C++ features.
The SHMEM application programing interface is implemented by the libsma library and is part of the Message Passing Toolkit (MPT) product on SGI systems. The SHMEM programming model consists of library routines that provide low-latency, high-bandwidth communication for use in highly parallelized, scalable programs. The routines in the SHMEM application programming interface (API) provide a programming model for exchanging data between cooperating parallel processes. The resulting programs are similar in style to Message Passing Interface (MPI) programs. You can use the SHMEM API alone or in combination with MPI routines in the same parallel program.
A SHMEM program is single program, multiple data (SPMD) in style. The SHMEM processes, called processing elements (PEs), all start at the same time, and they all run the same program. Usually the PEs perform computation on their own subdomains of the larger problem, and they periodically communicate with other PEs to exchange information to be used in the next computation phase.
The SHMEM routines minimize the overhead associated with data transfer requests, maximize bandwidth, and minimize data latency. Data latency is the period of time that starts when a PE initiates a data transfer and ends when a PE can use the data.
SHMEM routines support remote data transfer through the following:
put operations, which transfer data to a different PE.
get operations, which transfer data from a different PE.
Remote pointers, which allow direct references to data objects owned by another PE.
Other operations supported are collective broadcast and reduction, barrier synchronization, and atomic memory operations. An atomic memory operation is an atomic read-and-update operation, such as a fetch-and-increment, on a remote or local data object.
For more information, see the following:
The intro_shmem(3) man page.
The SGI MPI and SGI SHMEM User Guide.