CPU2006 Flag Description
Tyan Tyan YR190B8228, AMD Opteron 4174 HE

Test sponsored by Advanced Micro Devices

This result has been formatted using multiple flags files. The "default header section" from each of them appears next.


Default header section from x86-open64-423-flags-speed-revA

x86 Open64 Compiler Suite SPEC CPU2006 Flag Description

Compilers: x86 Open64 Compiler Suite



Default header section from amd-platform-speed-revA

Platform settings file


Base Compiler Invocation

C benchmarks

C++ benchmarks


Peak Compiler Invocation

C benchmarks

C++ benchmarks


Base Portability Flags

400.perlbench

401.bzip2

403.gcc

429.mcf

445.gobmk

456.hmmer

458.sjeng

462.libquantum

464.h264ref

483.xalancbmk


Peak Portability Flags

400.perlbench

401.bzip2

445.gobmk

456.hmmer

458.sjeng

462.libquantum

464.h264ref

483.xalancbmk


Base Optimization Flags

C benchmarks

C++ benchmarks


Peak Optimization Flags

C benchmarks

400.perlbench

401.bzip2

403.gcc

429.mcf

445.gobmk

456.hmmer

458.sjeng

462.libquantum

464.h264ref

C++ benchmarks

471.omnetpp

473.astar

483.xalancbmk


Implicitly Included Flags

This section contains descriptions of flags that were included implicitly by other flags, but which do not have a permanent home at SPEC.


System and Other Tuning Information

Linux Huge Page settings

In order to take full advantage of using x86 Open64's huge page runtime library, your system must be configured to use huge pages. It is safe to run binaries compiled with "-HP" on systems not configured to use huge pages, however, you will not benefit from the performance improvements huge pages offer. To configure your system for huge pages perform the following steps:

Note that further information about huge pages may be found in your Linux documentation file: /usr/src/linux/Documentation/vm/hugetlbpage.txt

HUGETLB_LIMIT

For the x86 Open64 compiler, the maximum number of huge pages an application is allowed to use can be set at run time via the environment variable HUGETLB_LIMIT. If not set, then the process may use all available huge pages when compiled with "-HP (or -HUGEPAGE)" or a maximum of n pages where the value of n is set via the compile time flag "-HP:limit=n".

Using numactl to bind processes and memory to cores

For multi-copy runs or single copy runs on systems with multiple sockets, it is advantageous to bind a process to a particular core. Otherwise, the OS may arbitrarily move your process from one core to another. This can effect performance. To help, SPEC allows the use of a "submit" command where users can specify a utility to use to bind processes. We have found the utility 'numactl' to be the best choice.

numactl runs processes with a specific NUMA scheduling or memory placement policy. The policy is set for a command and inherited by all of its children. The numactl flag "--physcpubind" specifies which core(s) to bind the process. "-l" instructs numactl to keep a process memory on the local node while "-m" specifies which node(s) to place a process memory. For full details on using numactl, please refer to your Linux documentation, 'man numactl'

Note that some versions of numactl, particularly the version found on SLES 10, we have found that the utility incorrectly interprets application arguments as it's own. For example, with the command "numactl --physcpubind=0 -l a.out -m a", numactl will interpret a.out's "-m" option as it's own "-m" option. To work around this problem, a user can put the command to be run in a shell script and then run the shell script using numactl. For example: "echo 'a.out -m a' > run.sh ; numactl --physcpubind=0 bash run.sh"

ulimit -s <n>

Sets the stack size to n kbytes, or unlimited to allow the stack size to grow without limit.

ulimit -l <n>

Sets the maximum size of memory that may be locked into physical memory.

OMP_NUM_THREADS

Sets the maximum number of OpenMP parallel threads auto-parallelized (-apo) applications may use.

O64_OMP_AFFINITY_MAP

Specifies the thread-CPU relationship when the operating system's affinity mechanism is used to assign OpenMP threads to CPUs.

O64_OMP_SPIN_USER_LOCK

Specifies whether or not to use the user-level spin mechanism for OpenMP locks. If the variable is set to TRUE then user-level spin mechanisms are used. If the variable is set to FALSE then pthread mutexes are used. The default if the variable is not set is the same as FALSE.

powersave -f (on SuSE)

Makes the powersave daemon set the CPUs to the highest supported frequency.

/etc/init.d/cpuspeed stop (on Red Hat)

Disables the cpu frequency scaling program in order to set the CPUs to the highest supported frequency.


Flag description origin markings:

[user] Indicates that the flag description came from the user flags file.
[suite] Indicates that the flag description came from the suite-wide flags file.
[benchmark] Indicates that the flag description came from a per-benchmark flags file.

The flags files that were used to format this result can be browsed at
http://www.spec.org/cpu2006/flags/x86-open64-423-flags-speed-revA.20101207.html,
http://www.spec.org/cpu2006/flags/amd-platform-speed-revA.html.

You can also download the XML flags sources by saving the following links:
http://www.spec.org/cpu2006/flags/x86-open64-423-flags-speed-revA.20101207.xml,
http://www.spec.org/cpu2006/flags/amd-platform-speed-revA.xml.


For questions about the meanings of these flags, please contact the tester.
For other inquiries, please contact webmaster@spec.org
Copyright 2006-2014 Standard Performance Evaluation Corporation
Tested with SPEC CPU2006 v1.1.
Report generated on Wed Jul 23 15:24:40 2014 by SPEC CPU2006 flags formatter v6906.