SPEC CPU2006 Config Files

Last updated: $Date: 2008-06-17 16:13:40 -0400 (Tue, 17 Jun 2008) $ by $Author: cloyce $
(To check for possible updates to this document, please see http://www.spec.org/cpu2006/Docs/ )

Overview

Click one of the following to go to the detailed contents about that item:

I. Introduction

II. Config file options for runspec

III. Config file options for specmake

IV. Config file options for the shell

V. Config file options for readers

VI. Using Feedback Directed Optimization (FDO)

VII. The config file preprocessor

VIII. Output files - and how they relate to your config file

IX. About Alternate Sources

X. Troubleshooting

Contents

I. Introduction

A. What is a config file? (Background: benchmark philosophy.)

B. What does a config file affect?

1. runspec

2. specmake

3. The shell

4. Readers of the results

5. The config file preprocessor

C. Config file structure

1. Comments and whitespace

2. Header section

3. Named sections

a. Precedence for the benchmark specifier

Default benchmark

Named suite

Named benchmark

Order of differing sections does not matter

Order of the same section does matter

b. Precedence for the tuning specifier

c. Precedence for the extension specifier

Extension found in config file

Extension not found in config file

Extension override

d. Combining specifier types

e. Precedence among section types

4. MD5 section

5. Shell-like "here documents" and continued lines

6. Included files

D. Variable substitution

1. By runspec

a. At startup: $[variable]

b. During a run: $variable and ${variable}

c. Example: cleaning files before a training run

d. Example: submit to multiple nodes, Tru64 Unix

e. Example: bind to processors, SPEC TurboBlaster9000

2. By the shell \$VARIABLE

a. Protecting shell variables

b. Example: submitting to multiple nodes, SGI Origin 2000

3. By specmake $(VARIABLE)

4. Limitations on variable substitution

5. Unsetting a variable with "%undef%"

II. Config file options for runspec

A. Precedence: config file vs. runspec command line

B. Options

action allow_extension_override backup_config basepeak bind build_in_build_dir check_md5 check_version command_add_redirect copies delay deletework difflines env_vars expand_notes expid ext fail fail_build fail_run feedback flagsurl http_proxy http_timeout ignore_errors ignore_sigint info_wrap_columns inherit_from iterations keeptmp line_width locking log_line_width log_timestamp mach mail_reports mailcompress mailmethod mailport mailserver mailto make make_no_clobber makeflags max_active_compares mean_anyway minimize_builddirs minimize_rundirs no_input_handler no_monitor nobuild notes_wrap_columns notes_wrap_indent output_format output_root parallel_setup parallel_setup_prefork parallel_setup_type parallel_test parallel_test_submit plain_train preenv rate rebuild reportable runlist section_specifier_fatal sendmail setprocgroup size src.alt strict_rundir_verify sysinfo_program table teeout train_with tune use_submit_for_speed verbose version_url

III. Config file options for specmake

CC, CXX, FC
CLD, CXXLD, FLD
ONESTEP
OPTIMIZE, COPTIMIZE, CXXOPTIMIZE, FOPTIMIZE
PORTABILITY, CPORTABILITY, CXXPORTABILITY, FPORTABILITY...
RM_SOURCES
PASSn_CFLAGS, PASSn_CXXFLAGS, PASSn_FFLAGS

About Automatic Rebuilds

IV. Config file options for the shell

A. Options

bench_post_setup fdo_pre0 fdo_preN fdo_make_cleanN fdo_pre_makeN fdo_make_passN fdo_post_makeN fdo_runN fdo_postN post_setup submit

B. Using and Changing fdo Options

C. Using submit

1. Basic Usage

2. Useful features related to submit

3. Continuation of Submit Lines

Sidebar: About Quoting and Submit

4. Reporting of submit usage

V. Config file options for readers

A. Descriptive fields

company_name hw_avail hw_cpu_name hw_cpu_char hw_cpu_mhz hw_disk hw_fpu hw_memory hw_model hw_nchips hw_ncores hw_ncoresperchip hw_ncpuorder hw_nthreadspercore hw_ocache hw_other hw_pcache hw_scache hw_tcache hw_vendor license_num machine_name prepared_by sw_auto_parallel sw_avail sw_base_ptrsize sw_compiler sw_file sw_os sw_parallel_defeat sw_parallel_other sw_state sw_other sw_peak_ptrsize tester tester_name test_date test_sponsor VENDOR

B. Field scoping and continuation

C. Additional notes for the reader

1 Notes sections

notes_comp_NNN notes_port_NNN notes_base_NNN notes_peak_NNN notes_submit_NNN notes_os_NNN notes_plat_NNN notes_part_NNN notes_NNN

2 Note numbering

3 Additional tags

4 Links in notes sections

5 Attachments

D. About Auto Parallel Reporting

VI. Using Feedback Directed Optimization (FDO)

A. The minimum requirement: PASSn* or fdo*n

B. Combining PASS*n and fdo*n; fake is your friend

C. Interaction with the config file feedback option

D. If the config file feedback option is used at multiple levels

E. Interaction with runspec --feedback

F. More examples

VII. The config file preprocessor

A. Defining macros

B. Un-doing macro definition

C. Using macros

D. Conditionals

1. %ifdef .. %endif

2. %ifndef .. %endif

3. %if .. %endif

4. %else

5. %elif

E. Informational directives

1. %warning

2. %error

VIII. Output files - and how they relate to your config file

A. Automatic backup of config files

B. The log file and verbosity levels

1. Useful Search Strings

2. About Temporary Debug Logs

3. Definitions of verbosity levels

C. Log file example: Feedback-directed optimization.

D. Help, I've got too many logs

E. Finding the build directory

F. Files in the build directory

G. For more information

IX. About Alternate Sources

A. Example: Applying a src.alt

B. Developing a src.alt (brief introduction)

X. Troubleshooting

I. Introduction

I.A. What is a config file? (Background: benchmark philosophy.)

A config file contains:

• The instructions for building the benchmarks.
• The instructions for running the benchmarks.
• The description of the system under test.
• The key to result reproducibility.
• The guts, the real controls, the Good Stuff.
• The place where the benchmark philosophy hits the road.

A key decision that must be made by designers of a benchmark suite is whether to allow the benchmark source code to be changed when the suite is used.

If source code changes are allowed:

If source code changes are not allowed:

SPEC has chosen not to allow source code changes for the CPU2006 suite, except under very limited circumstances.

By restricting source code changes, SPEC separates the activity of porting benchmarks, which has a goal of being performance neutral, from the activity of using the benchmarks, where the goal is getting the best score possible. Prior to the first production use of CPU2006, SPEC invested substantial effort to port the suite to as many platforms as practical, including 32 and 64-bit systems; little-endian and big-endian hardware; Unix, Linux, Mac OS X, and Microsoft Windows systems.

Are source code changes ever allowed? Normally, no. But if you discover a reason why you believe such a change is essential, SPEC wants to hear about it, and will consider such requests for a future revision of the suite. SPEC will normally not publish CPU2006 results using modified source code, unless such modifications are unavoidable for the target environment, are reviewed by SPEC, are made available to all users of the suite, and are formally approved by a vote.

So, if source code changes are not allowed, but the benchmarks must be compiled in a wide variety of environments, can the users at least write their own makefiles, and select -D options to select different environments? The answer to these two questions are "no", and "yes", respectively:

• No, you can't write your own makefiles.
• But yes, you can select portability options (such as -D).

You do this in the config file, which contains a centralized collection of all the portability options and optimization options for all the benchmarks in the CPU2006 suite. The SPEC tools then automatically generate the makefiles for you.

The config file contains places where you can specify the characteristics of both your compile time and run time environments. It allows the advanced user to perform detailed manipulation of makefile options, but retains all the changes in one place so that they can be examined and reproduced.

The config file is one of the key ingredients in making results reproducible. For example, if a customer would like to run the CPU2006 suite on her own SuperHero Model 4 and discover how close results are in her environment to the environment used when the vendor published a CPU2006 result, she should be able to do that using only 3 ingredients:

1. The SPEC CPU2006 media, ordered from SPEC.
2. The software and hardware as specified in the full disclosure when the vendor published the original results.
3. The config file from the vendor's submission.

I.B. What does a config file affect?

A config file contains options targetting five distinct consumers:

1. The runspec tool, which provides overall control of the test,
2. The tool that compiles benchmarks: specmake,
3. Your shell, which is used for certain operations such as submiting to specific processors,
4. Readers of the results, and
5. The config file preprocessor.

To understand how to write a config file effectively, you need to understand which consumer you are addressing at any given point.

The above point seems worth emphasizing:

To understand how to write a config file effectively, you need to understand which consumer you are addressing at any given point.

This section gives you an overview of the consumers; more detail is included in later sections.

I.B.1. runspec

Various aspects of the operation of runspec can be affected by setting options within a config file. You'll find a list of these options in the table of contents for section II - including some that are available both on the runspec command line and some that can only be set within a config file.

For example, if michael.cfg includes the lines:

   output_format = asc,ps
   tune          = base
   reportable    = 1
   runlist       = fp

then the defaults for the runspec command would change as specified. A user who types either of the following two commands would get precisely the same effect:

   runspec --config=michael
   runspec --config=michael --output=asc,ps --tune=base --reportable fp 

I.B.2. specmake

The tool specmake is simply GNU make renamed to avoid any possible conflicts with other versions of make that may be on your system. The options commonly used for specmake are listed in the table of contents for section III.

For example, these config file lines:

   CC           = cc
   CPORTABILITY = -DSPEC_CPU_LP64
   OPTIMIZE     = -O4

are written to the makefile set that is ultimately used to build the benchmark, and are interpreted by specmake.

I.B.3. The shell

Some config file lines define commands that are handed off to the shell or, on Windows, the command interpreter. The list of these is in the table of contents for section IV.

For example, consider a config file that contains:

   fdo_pre0     = mkdir /tmp/joydeep/feedback; rm -f /tmp/joydeep/feedback/* 

When using this config file, runspec will pass the above command to the shell prior to running a training run for feedback directed optimization. It is the shell that actually carries out the requested commands, not runspec, so the syntax of the command depends on whether you are using the Unix shell (/bin/sh) or the Windows command interpreter (cmd.exe).

Because runspec can cause arbitrary commands to be executed, it is therefore important to read a config file you are given before using it.

I.B.4. Readers of the results

If a SPEC CPU2006 result is published (for example, at http://www.spec.org/), it is expected to contain all the information needed for a reader to understand exactly what was tested. Fields that are informative for readers are listed in the table of contents for section V.

For example, config file lines such as these are addressed to the human reader:

   hw_avail  = Apr-2008
   sw_avail  = May-2008
   notes_base_015  = Note: Feedback directed optimization was not used

In addition, for results published by SPEC, the config file itself is available to readers at http://www.spec.org/cpu2006/. The config file is presented as you wrote it, with three exceptions (protected comments, the MD5 section, and rawfile corrections for reader fields). The config file is made available because it is so important to reproducing results, as described in the Introduction. The config file is saved on every run, as a compressed portion of the rawfile, and can be accessed with runspec --rawformat --output_format=config <rawfile>.

I.B.5. The config file preprocessor

There is also a config file preprocessor, which is addressed via lines that begin with % in the first column. (The config file preprocessor is new with CPU2006.)

I.C. Config file structure

A config file contains:

• A header section.
• An arbitrary number of user-defined named sections, delimited by section markers.
• An automatically-generated MD5 section.

About "scope": Every line of the config file is considered to be within the scope of one of the above three. Lines prior to the first section marker are in the scope of the header section. All other lines are either in the scope of the most recently preceding user-defined section marker, or else in the MD5 section.

A line within the scope of a named section may be overridden by a line within the scope of a different named section, according to rules that are described below.

I.C.1. Comments and whitespace

   #> I didn't use the C++ beta version because of Bob's big back-end bug.

   CC_PATH=/path/with/no/trailing/spaces  

   CC_PATH=/path/with/trailing/spaces\ 

   OPTIMIZE=-O2
   OPTIMIZE   =  -02

One place where spaces are considered significant is in notes, where the tools assume you are trying to line up your comments in the full disclosure reports. (Notes are printed in a fixed-width font.)

Spaces at the beginning of lines are ignored, except when attempting to address the preprocessor. Preprocessor directives always begin with a percent sign (%) in the first column. You can put spaces after the percent sign, if you wish, as shown by the examples below.

I.C.2. Header section

The header section is simply the first section, prior to the first occurence of a named section.

Most attempts to address runspec itself must be done in the header section. For example, if you want to set reportable=1, you must do so before any occurrences of section markers.

I.C.3. Named Sections

A named section is a portion of the config file that begins with a section marker and continues until the next section marker or the MD5 section is reached. The contents of the named section are applied based upon the precedence rules described in the following sections.

A "section marker" is a one- to four-part string of the form:

   benchmark[,...]=tuning[,...]=extension[,...]=machine[,...]:

These are referred to below as the 4 "section specifiers". The allowed values for the section specifiers are:

Trailing default section specifiers may be omitted from a section marker. Thus all three of these section markers are equivalent:

   465.tonto=base=default=default:
   465.tonto=base=default:
   465.tonto=base:

[*] The "machine" specifier works similarly to the extension specifier, but it does not affect the name of the executable produced, which, in many environments, makes it less useful than the extension specifier. This document does not describe the usage of the "machine" specifier, other than to note that it exists; if you feel particularly courageous, you can experiment with it.

But please be aware that if you use a single config file to build with two different machine settings, you will likely overwrite the original binaries on the second build, since the machine specifier does not affect the name of the generated executable.

An example of the usage of the machine specifier may be found in your config directory, in Example-solaris-sparc-sunstudio.cfg. That config file applies -DSPEC_CPU_LP64 when the machine native64 is selected; it also takes steps to work around the limitation mentioned in the previous paragraph.

Section markers can be entered in any order. Section markers can be repeated; material from identical section markers will automatically be consolidated. That is, you are welcome to start one section, start a different one, then go back and add more material to the first section. But please note that since there is no marker for the header section, you cannot go back to it.

By constructing section markers, you specify how you would like your options applied, with powerful defaulting and overriding capabilities. The next several sections walk through examples to demonstrate precedence, including how sections interact with each other.

I.C.3.a. Precedence for the benchmark specifier

For the benchmark specifier, the precedence is:

  highest   named benchmark(s)
            suite name
  lowest    default

Using default as the benchmark specifier

For example, consider this config file that only mentions default for the benchmark specifier:

   $ cat tmp.cfg
   runlist       = sjeng
   size          = test
   iterations    = 1
   tune          = base
   output_format = text
   teeout        = 1

   default=default=default=default:
   OPTIMIZE = -xO1 -w

   $ runspec --config=tmp | grep sjeng.c
   cc -c -o sjeng.o -DSPEC_CPU -DNDEBUG   -xO1 -w    sjeng.c
   $ 

The config file above is designed for quick, simple testing: it runs only one benchmark, namely 458.sjeng, using the smallest (test) workload, runs it only once, uses only base tuning, outputs only the text-format (ASCII) report, and displays the build commands to the screen (teeout). To use it, we issue a runspec command, and pipe the output to grep to search for the actual generated compile command. (Alternatively, on Windows, we could use findstr on the generated log file).

The careful reader may ask, "Why does the runlist reference sjeng rather than 458.sjeng?" The answer is that the runlist can use benchmark numbers or any abbreviation that is sufficient for uniqueness; any of the following would have the same effect: "458.sjeng", "458", "sjeng", "sj", "458.sj". This is the same rule as for the corresponding option on the command line.

The results show that the tuning applied was the expected -xO1 -w (which mean optimization level 1 and suppress warnings, for the Sun Studio Compilers). The tools have automatically added -c -o sjeng.o to specify where the object file is to be written. The switches -DSPEC_CPU -DNDEBUG were also added automatically. The former may enable benchmark code changes from SPEC's porting process (if any), and the latter turns off C language "assert" statements (if any).

Using a named suite as the benchmark specifier

The next example differs from the previous one by adding a section marker with int, for the integer suite, as the first section specifier:

   $  cat tmp.cfg
   runlist       = sjeng
   size          = test
   iterations    = 1
   tune          = base
   output_format = text
   teeout        = 1

   default=default=default=default:
   OPTIMIZE = -xO2 -w

   int=default=default=default:
   OPTIMIZE = -xO3 -w

   $ runspec --config=tmp | grep sjeng.c
   cc -c -o sjeng.o -DSPEC_CPU -DNDEBUG   -xO3 -w     sjeng.c
   $

The second OPTIMIZE line is used above because the reference to the integer suite is considered to be more specific than the overall default.

Newly documented with CPU2006 V1.1: you can also mention the "bsets" found in $SPEC/benchspec/CPU2006 or %SPEC%\benchspec\CPU2006. For example, you could reference all the C++ benchmarks by saying:

   all_cpp=default=default=default:
   OPTIMIZE = -xO3 -w

You can mention multiple sets:

   all_c,all_cpp=default=default=default:
   OPTIMIZE = -xO3 -w

Using a named benchmark as the benchmark specifier

Furthermore, we can add a specifier that mentions sjeng by name:

   $  cat tmp.cfg
   runlist       = sjeng
   size          = test
   iterations    = 1
   tune          = base
   output_format = text
   teeout        = 1

   default=default=default=default:
   OPTIMIZE = -xO2 -w

   int=default=default=default:
   OPTIMIZE = -xO3 -w

   458.sjeng=default=default=default:
   OPTIMIZE = -xO4 -w

   $ runspec --config=tmp | grep sjeng.c
   cc -c -o sjeng.o -DSPEC_CPU -DNDEBUG   -xO4 -w      sjeng.c
   $

The third OPTIMIZE line wins above, because it is included in the section that is considered to be the most specific.

Newly documented with CPU2006 V1.1: You can name more than one benchmark if you wish, as in:

   401.bzip2,458.sjeng=default=default=default:
   OPTIMIZE = -xO4 -w

Order of differing sections does not matter:

Let's change the example from the previous section to a different order.

   $ cat tmp.cfg
   runlist       = sjeng
   size          = test
   iterations    = 1
   tune          = base
   output_format = text
   teeout        = 1

   458.sjeng=default=default=default:
   OPTIMIZE = -xO4 -w

   default=default=default=default:
   OPTIMIZE = -xO2 -w

   int=default=default=default:
   OPTIMIZE = -xO3 -w

   $ runspec --config=tmp | grep sjeng.c
   cc -c -o sjeng.o -DSPEC_CPU -DNDEBUG   -xO4 -w      sjeng.c

Notice above that the order of entry is not significant; it's the order of precedence from least specific to most specific.

Order of the same section does matter:

When a specifier is listed more than once at the same descriptive level, the last instance of the specifier is used. Consider this case:

   458.sjeng=default=default=default:
   OPTIMIZE = -xO4

   400.perlbench=default:
   OPTIMIZE = -fast

   458.sjeng=default=default=default:
   OPTIMIZE = -xO3

The ending value of OPTIMIZE for 458.sjeng is -xO3, not -xO4.

I.C.3.b. Precedence for the tuning specifier

For the tuning specifier, either base or peak has higher precedence than default.

Here is an example of its use:

   $ cat tmp.cfg
   runlist       = sjeng
   size          = test
   iterations    = 1
   tune          = base,peak
   output_format = text
   teeout        = 1

   default=default=default=default:
   CC       = /opt/SUNWspro/bin/cc -w

   default=base=default=default:
   CC       = /update1/bin/cc -w

   default=peak=default=default:
   CC       = /update2/bin/cc -w

   $ runspec --config=tmp | grep sjeng.c
   /update1/bin/cc -w -c -o sjeng.o -DSPEC_CPU -DNDEBUG    sjeng.c
   /update2/bin/cc -w -c -o sjeng.o -DSPEC_CPU -DNDEBUG    sjeng.c
   $ 

In the above example, we compile sjeng twice: once for base tuning, and once for peak. Notice that in both cases the compilers defined by the more specific section markers have been used, namely /update1/bin/cc and /update2/bin/cc, rather than /opt/SUNWspro/bin/cc from default=default=default=default.

I.C.3.c. Precedence for the extension specifier

For the extension specifier, any named extension is at a higher precedence level than the default.

Using an extension found in the config file

The next example, builds with either the library for the "bsdmalloc" memory allocation routines, or the multi-threaded "mtmalloc" routines. (Note: the SPEC CPU2006 benchmarks do not require multi-threading, and do not contain threading directives; but a compiler is allowed to choose to try to automatically decompose threads, and there's nothing in the run rules to prohibit you from linking with your preferred version of a supported malloc library.)

   $ cat tmp.cfg
   runlist       = sjeng
   size          = test
   iterations    = 1
   tune          = base
   output_format = text
   teeout        = 1

   default=default=default:
   LIBS = -lslowmalloc

   default=default=myke:
   LIBS = -lbsdmalloc

   default=default=yusuf:
   LIBS = -lthread -lmtmalloc
   $
   $ runspec --config=tmp --extension=myke | grep sjeng.o
   cc -c -o sjeng.o -DSPEC_CPU -DNDEBUG                    sjeng.c
   cc  attacks.o book.o crazy.o draw.o ecache.o epd.o eval.o leval.o moves.o 
   neval.o partner.o proof.o rcfile.o search.o see.o seval.o sjeng.o ttable.o 
   utils.o     -lbsdmalloc          -o sjeng
   $
   $ runspec --config=tmp --extension=yusuf | grep sjeng.o
   cc -c -o sjeng.o -DSPEC_CPU -DNDEBUG                    sjeng.c
   cc  attacks.o book.o crazy.o draw.o ecache.o epd.o eval.o leval.o moves.o 
   neval.o partner.o proof.o rcfile.o search.o see.o seval.o sjeng.o ttable.o 
   utils.o     -lthread -lmtmalloc          -o sjeng
   $ 
   $ cd $SPEC/benchspec/CPU2006/458.sjeng/exe
   $ ls -lt | head -3
   total 5888
   -rwxrwxr-x   1 alan  staff      244688 May 11 16:32 sjeng_base.yusuf
   -rwxrwxr-x   1 alan  staff      244628 May 11 16:31 sjeng_base.myke
   $ 

Notice above that two different versions of sjeng were built from the same config file, and neither one used slowmalloc, since the named extension is higher priority than the default. Both executables are present in the exe directory for 458.sjeng.

Using an extension that is not found in the config file

The previous section demonstrated use of the runspec switch --extension to select among extensions defined in the config file. But what if the extension on the command line is not mentioned in the config file? The example below continues immediately from the example just above:

   $ runspec --config=tmp --extension=yusoff
   runspec v4200 - Copyright 1999-2006 Standard Performance Evaluation Corporation
   ...
   ERROR: The extension 'yusoff' defines no settings in the config file!
          If this is okay and you'd like to use the extension to just change
          the extension applied to executables, please put
       allow_extension_override = yes
          into the header section of your config file.

By default, if you mention an extension on the runspec command line that does not exist in the config file, the tools refuse to build.

Extension override

But if you add allow_extension_override=yes to the top of the config file, then the tools will build or run with the extension you specified, using the same settings as they would have used if no extension had been entered on the runspec command line.

The next example continues with a config file that adds allow_extension_override to the previous example config file:

   $ diff tmp.cfg tmp2.cfg
   0a1
   > allow_extension_override=yes
   $
   $ runspec --config=tmp2 --extension=yusoff | grep sjeng.o
   cc -c -o sjeng.o -DSPEC_CPU -DNDEBUG                    sjeng.c
   cc attacks.o book.o crazy.o draw.o ecache.o epd.o eval.o leval.o moves.o 
   neval.o partner.o proof.o rcfile.o search.o see.o seval.o sjeng.o ttable.o 
   utils.o           -lslowmalloc          -o sjeng
   $
   $ cd $SPEC/benchspec/CPU2006/458.sjeng/exe
   $ ls -lt | head -2
   total 6384
   -rwxrwxr-x   1   alan   staff        244628 May 11 16:39 sjeng_base.yusoff

Notice above that although the tools now consent to build with the requested extension, the library settings now falls back to the default, since "yusoff" does not match any section markers.

(For CPU2000, the tools silently accepted any extension, including typos, which sometimes led to surprising results. CPU2006 tries to reduce surprises by rejecting your typos, unless you set allow_extension_override.)

I.C.3.d. Combining specifier types

If more than one section applies to a particular benchmark without disagreement among them, then all are applied.

Consider this example:

   $ cat tmp.cfg
   runlist       = sjeng
   size          = test
   iterations    = 1
   tune          = base
   output_format = text
   teeout        = 1

   default=default=default=default:
   OPTIMIZE = -xO2 -w
   CC       = /opt/SUNWspro/bin/cc 
   LIBS     = -lbsdmalloc

   458.sjeng=default=default=default:
   OPTIMIZE = -xO4 -w

   default=peak=default=default:
   CC       = /update1/bin/cc 

   default=default=mt=default:
   LIBS     = -lthread -lmtmalloc

   $ runspec --config=tmp --tune=peak --ext=mt | grep sjeng.o
   /update1/bin/cc  -c -o sjeng.o -DSPEC_CPU -DNDEBUG   -xO4 -w  sjeng.c
   /update1/bin/cc   -xO4 -w attacks.o book.o crazy.o draw.o ecache.o epd.o 
   eval.o leval.o moves.o neval.o partner.o proof.o rcfile.o search.o see.o 
   seval.o sjeng.o ttable.o utils.o    -lthread -lmtmalloc         -o sjeng
   $ 

Notice above that all three sections applied: the section specifier for 458.sjeng, the specifier for peak tuning, and the specifier for extension mt.

I.C.3.e. Precedence among section types

If sections conflict with each other, the order of precedence is:

     highest     benchmark
                 suite
                 tuning
     lowest      extension

And this order can be demonstrated as follows:

    $  cat tmp.cfg
     runlist       = sjeng
     size          = test
     iterations    = 1
     tune          = base
     output_format = text
     teeout        = 1
     makeflags     = -j30
  
     default=default=default=default:
     OPTIMIZE = -xO1 -w
  
     int=default=default=default:
     OPTIMIZE = -xO2 -w
  
     458.sjeng=default=default=default:
     OPTIMIZE = -xO3 -w
  
     default=peak=default=default:
     OPTIMIZE = -xO4 -w
  
     default=default=mt=default:
     OPTIMIZE = -xO5 -w
     $
     $ runspec --config=tmp sjeng | grep sjeng.c  
[1]  cc -c -o sjeng.o -DSPEC_CPU -DNDEBUG   -xO3 -w        sjeng.c
     $ runspec --config=tmp --tune=peak sjeng | grep sjeng.c
[2]  cc -c -o sjeng.o -DSPEC_CPU -DNDEBUG   -xO3 -w        sjeng.c
     $ runspec --config=tmp --extension=mt sjeng | grep sjeng.c
[3]  cc -c -o sjeng.o -DSPEC_CPU -DNDEBUG   -xO3 -w        sjeng.c
     $ 
     $ runspec --config=tmp --tune=base bzip | grep bzip2.c
[4]  cc -c -o bzip2.o -DSPEC_CPU -DNDEBUG   -xO2 -w        bzip2.c
     $ runspec --config=tmp --tune=peak bzip | grep bzip2.c
[5]  cc -c -o bzip2.o -DSPEC_CPU -DNDEBUG   -xO2 -w        bzip2.c
     $ runspec --config=tmp --extension=mt bzip | grep bzip2.c
[6]  cc -c -o bzip2.o -DSPEC_CPU -DNDEBUG   -xO2 -w        bzip2.c
     $ 
     $ runspec --config=tmp --tune=base sphinx3 | grep utt.c
[7]  cc -c -o utt.o -DSPEC_CPU -DNDEBUG -I. -DSPEC_CPU -DHAVE_CONFIG_H 
     -I. -Ilibutil   -xO1 -w   utt.c
     $ runspec --config=tmp --tune=peak sphinx3 | grep utt.c
[8]  cc -c -o utt.o -DSPEC_CPU -DNDEBUG -I. -DSPEC_CPU -DHAVE_CONFIG_H 
     -I. -Ilibutil   -xO4 -w   utt.c
     $ runspec --config=tmp --extension=mt sphinx3 | grep utt.c
[9]  cc -c -o utt.o -DSPEC_CPU -DNDEBUG -I. -DSPEC_CPU -DHAVE_CONFIG_H 
     -I. -Ilibutil   -xO5 -w   utt.c
     $ runspec --config=tmp --tune=peak --extension=mt sphinx3 | grep utt.c
[10] cc -c -o utt.o -DSPEC_CPU -DNDEBUG -I. -DSPEC_CPU -DHAVE_CONFIG_H 
     -I. -Ilibutil   -xO4 -w   utt.c
     $ 

Notice above that the named benchmark always wins: lines [1], [2], and [3]. If there is no section specifier that names a benchmark, but there is a section specifier that names a suite, then the suite wins: lines [4], [5], and [6]. If there are no applicable benchmark or suite specifiers, then tuning or extension can be applied: lines [8] and [9]. But if both tuning and extension are applied, tuning wins [10].

I.C.4. MD5 Section

The final section of your config file is generated automatically by the tools when the benchmarks are compiled, and looks something like this:

   __MD5__
   458.sjeng=base=none=default:
   # Last updated Thu May 11 08:53:12 2006
   optmd5=a0104c0975ee3b341e73437843df57a9
   baggage=
   compile_options=\
   @eNpz9vcNsFJITlbQBaJ8hfyCksz8vGK9fAVdl+AAV+d454BQINPPxdUp1F1BQUG3wt9YQbdcAR3Y\
   FOeXFiWn2nE5Wyk4O9sqJScrgZn+Tl7+ASG2SiimK3EBrQQa7Obj6B4MlMO0SYnL30oBqNHT1zPK\
   FagCYqsSl4+nnzfYtVgcYpOflJWaXFJshySGsBPkGh8XiMOwmw1W4B8KciySSwGYpEmr
   exemd5=9b42a21f12b1fbb4e87cd9bacd781c43

The "MD5" is a checksum that ensures that the binaries referenced in the config file are in fact built using the options described therein. For example, if you edit the config file to change the optimization level for 458.sjeng, the next time the file is used for sjeng, the tools will notice the change and will recompile it.

You can optionally disable this behavior, but doing so is strongly discouraged. See the acerbic remarks in the description of check_md5, below.

If you would like to see what portions of your config file are used in computing the MD5 hash, runspec with --debug=30 or higher, and examine the log file.

For published results, the published config file (from rawformat --output_format=config) does not include the MD5 section.

I.C.5. Shell-like "here documents" and continued lines

Shell-style "here documents" are supported for setting variables to multi-line values. Continued lines (with \) are also supported:

   $ cat tmp2.cfg
   expand_notes  = 1
   size          = test
   runlist       = sjeng
   iterations    = 1
   output_format = text

   foo =<<EOT

   This +
   is a +
   test +
   EOT

   bar = \
         and +\
         so  +\
         is  +\
         this+

   notes01 = $foo
   notes02 = $bar

   $ runspec --config=tmp2 | grep txt
           format: ASCII -> /ailuropoda/raj/spec/result/CINT2006.159.test.txt
   $ grep + ../result/*159*txt
       This +
       is a +
       test +
             and +
             so  +
             is  +
             this+
   $

Note: although continued lines are supported, they are rarely used. The more common method of continuation is by appending a number to a field, as described in the section "Field scoping and continuation".

I.C.6. Included files

It is possible to include another file in your config file. A typical use for this feature might be to keep all the software information in the main config file, but to include the hardware information about the current System Under Test (SUT) in another file. For example:

   $ cat tmp.cfg
   output_format = text
   iterations    = 1
   size          = test
   sw_compiler   = myC V1.0
   sw_avail      = Mar-2007
   runlist       = sjeng
   include: SUT.inc

   default=base:
   OPTIMIZE = -O
   $ cat SUT.inc
   hw_model = SuperHero IV
   hw_avail = Feb-2008

   $ runspec --config tmp | grep txt
           format: ASCII -> /manas/spec/result/CINT2006.160.test.txt
   $ grep avail ../result/*160.test.txt
    [...]       Hardware availability: Feb-2008
    [...]       Software availability: Mar-2007
   $ 

Notice above that the report mentions both the hardware and software dates.

I.D. Variable Substitution

I.D.1. By runspec

Substitution by runspec itself uses two different methods: the first is immediately after the config file is read, and the second is via Perl variable interpolation.

I.D.1.a At startup: $[variable]

Substitution for variables of the form $[variable] happens immediately after the config file is read. Any value that's set in the config file and is visible in the scope where the variable is used can be substituted. Because of the named section scoping restriction, if you want to use variable substitution to note your optimization flags, the notes for the individual benchmarks must be in those benchmarks' sections:

400.perlbench=peak=default=default:
PEAKFLAG=-gofast
# The following will turn into what you expect
notes_peak_400_1=I use $[PEAKFLAG]

400.perlbench=base=default=default:
BASEFLAG=-besafe
# The following will turn into what you expect:
notes_base_400_1=I use $[BASEFLAG]
# The following will NOT WORK:
notes_base_400_2=My brother likes $[PEAKFLAG]

You can't substitute variables that don't exist or whose values aren't known when the config file is read.

Wrong:

ext = foo

default:
OPTIMIZE = -xO2
notes01 = my ext is $[ext]

default=default=bar:
OPTIMIZE = -xO1
notes02 = my ext is $[ext]

This doesn't work because the sorting of which extensions to use doesn't happen until after the config file is processed. In this particular example, it's obvious (to you) what the value should be, but the tools aren't as clever as you are.

Perhaps the most useful variable is the one for the top of the SPEC CPU2006 tree, $[top], often found in contexts such as:

    flagsurl = $[top]/myflagsdir/myflagsfile.xml

Variables of possible interest might include:

You can substitute for most options that you enter into the config file, including: action, allow_extension_override, backup_config, basepeak, check_md5, check_version, command_add_redirect, config, copies, delay, deletework, difflines, env_vars, expand_notes, expid, ext, fake, feedback, flagsurl, http_proxy, http_timeout, ignore_errors, ignore_sigint, info_wrap_columns, iterations, line_width, locking, log_line_width, mach, mail_reports, mailcompress, mailmethod, mailport, mailserver, mailto, make, make_no_clobber, makeflags, max_active_compares, mean_anyway, minimize_builddirs, minimize_rundirs, no_input_handler, no_monitor, notes_wrap_columns, notes_wrap_indent, output_format, output_root, plain_train, rate, rawformat, rebuild, reportable, runlist, section_specifier_fatal, sendmail, setprocgroup, size, strict_rundir_verify, sysinfo_program, table, teeout, tune, use_submit_for_speed, username, verbose, version_url.

You can also print out the value of additional variables that you may have created.

Here is a sample config file that illustrates square bracket variable substitution:

$ cat x.cfg
expand_notes = 1
runlist      = fp
action       = validate
myfriend     = jamiemeow
output_root  = /tmp
flagsurl     = $[top]/Docs/flags/flags-advanced.xml

notes01      = Today, I am running $[runlist] in $[top] on a $[OS] system 
notes02      = Today the flags file is $[flagsurl]
notes03      = Today, my favorite friend is $[myfriend]

$ runspec --config=x  --fakereportable | grep txt
        format: ASCII -> /tmp/result/CFP2006.002.txt
$ grep Today /tmp/result/CFP2006.002.txt
     Today, I am running fp in /spec/cpu2006 on a unix system 
     Today the flags file is /spec/cpu2006/Docs/flags/flags-advanced.xml
     Today, my favorite friend is jamiemeow

You can't use square brackets to substitute variables whose value changes during a run or build.

Wrong:

default=default=default=default:
#        I executed ''
notes0 = I executed '$[command]'

What did you expect?

Don't worry -- you'll receive a warning if you use a variable that the tools don't know about. It's up to you to heed them.

I.D.1.b During a run: $variable, ${variable}

The second round uses Perl variable interpolation. Only Perl scalars (denoted by a leading $) can be interpolated. For example, notes001 below uses the log file number (generated by the tools) and the hardware availability date (which was set directly):

$ cat tmp.cfg
runlist       = mcf
tune          = base
size          = test

iterations    = 1
output_format = asc

expand_notes  = 1
hw_avail      = May-2006
notes001      = This run is from log.$lognum with hw_avail $hw_avail

$ runspec -c tmp | grep txt
        format: ASCII -> /spec/david/result/CINT2006.029.test.txt
$ grep with ../result/*029*txt
     This run is from log.029 with hw_avail May-2006
$ 

In this case, $hw_avail could also have been substituted in the first round by writing it as $[hw_avail]. In general, for variable interpolation, the earlier the better.

To put text immediately after a variable, you need to make it possible for the parser to see the variable that you want, by using braces:

   % tail -2 tmp.cfg
   notes001 =You have done ${lognum}x runs tonight, go to bed.

   % runspec -c tmp | grep txt
      format: ASCII -> /john/result/CINT2006.103.test.txt
   % grep done /john/result/CINT2006.103.test.txt
      You have done 103x runs tonight, go to bed.

Interpolation won't always do what you wish it might do: for example, some variables are only defined at certain times, and your submit or notes line might be interpolated at a different time. When debugging a config files that uses variable interpolation, you will probably find --size test useful.

Some things that you might choose to interpolate include:

For example, let's say you want to go for minimal performance. You might want to do this with the nice command. You can say:

   submit=nice 20 '$command'

and the $command gets expanded to whatever would normally be executed but with nice 20 stuck in front of it.

If you'd like a complete list of the variables that you can use in your commands (relative to the config file you're using), set runspec's verbosity to 35 or higher (-v 35) and do a run that causes a command substitution to happen, with expand_notes=1.

I.D.1.c Example: cleaning files before a training run

Perhaps a more useful example is this one, which directs the shell to clean files related to the current executable in the temporary directory, before a training run for feedback directed optimization:

   fdo_pre0     = mkdir /tmp/pb; rm -f /tmp/pb/${baseexe}*

NOTICE in this example that although the commands are carried out by the shell, the variable substitution is done by runspec.

I.D.1.d Example: submit to multiple nodes, Tru64 Unix

The following lines submit to multiple nodes on a Compaq AlphaServer SC Series Supercomputer running Tru64 Unix:

   submit= echo "$command" > dobmk; prun -n 1 sh dobmk
   command_add_redirect=1

In this example, the command that actually runs the benchmark is written to a small file, dobmk, which is then submitted to a remote node selected by prun. The parallel run command, prun, can execute multiple copies of a process, but in this case we have requested just one copy by saying -n 1. The SPEC tools will create as many copies as required.

The command_add_redirect is crucial. What happens without it?

$ head prun1.cfg
submit= echo "$command" > dobmk; prun -n 1 sh dobmk

ext            = prun
action         = validate
runlist        = libquantum
size           = test
use_submit_for_speed = 1
iterations     = 1        
ignore_errors  = 1
output_format  = text
$ runspec -c prun1.cfg 
...
$ cd $SPEC/benchspec/CPU2006/462.libquantum/run/run_base_test_prun.0000/
$ cat dobmk 
../run_base_test_prun.0000/libquantum_base.prun 33 5
$ 

Now let's use command_add_redirect, and see how dobmk changes:

$ diff prun1.cfg prun2.cfg 
1a2
> command_add_redirect=1
$
$ runspec -c prun1.cfg 
...
$ cd $SPEC/benchspec/CPU2006/462.libquantum/run/run_base_test_prun.0000/
$ cat dobmk 
../run_base_test_prun.0000/libquantum_base.prun 33 5 > test.out 2>> test.err
$ 

Notice that with command_add_redirect=1, the substitution for $command includes both the name of the executable and the file assignments for standard in, standard out, and standard error. This is needed because otherwise the files would not be connected to libquantum on the remote node. That is, the former generates [*]:

echo "libquantum_base.prun 33 5" > dobmk; 
prun -n 1 sh dobmk > test.out 2>> test.err

And the latter generates [*]:

echo "libquantum_base.prun 33 5 > test.out 2>> test.err" > dobmk; 
prun -n 1 sh dobmk

[*] The picky reader may wish to know that the examples were editted for readability: a line wrap was added, and the directory string .../run_base_test_prun.0000/ was omitted. The advanced reader may wonder how the above lines were discovered: for the former, we found out what runspec would generate by going to the run directory and typing specinvoke -n, where -n means dry run; in the latter, we typed specinvoke -nr, where -r means that $command already has device redirection. For more information on specinvoke, see utility.html.

I.D.1.e Example: bind to processors, SPEC TurboBlaster9000

The following lines bind copies to individual processors on a SPEC TurboBlaster 9000 running *nix:

   bind= 0, 4, 8, 12, 16, 20
   submit= procbind -p $BIND $command

In this example, the list of processors to bind is set using the bind facility, which is then used as an argument to the procbind command. With these settings, the first copy will be bound to processor 0, the second to processor 4, the third to processor 8, and so on. If more than six copies are run, the list is re-used starting from the beginning; that is, copy seven would also be bound to processor 0 and so on.

An equivalent way to say the same as the above would be

   bind0= procbind -p 0
   bind1= procbind -p 4
   bind2= procbind -p 8
   bind3= procbind -p 12
   bind4= procbind -p 16
   bind5= procbind -p 20
   submit= $BIND $command

The content of each of the bind settings need not be the same, or even similar.

Two important notes about the above submit commands:

1. $BIND must be spelled exactly as it is in the examples above. It is a limitation of the tools that saying things like ${BIND} just won't work.
2. For bind settings that contain whitespace or commas, the second form (multiple assignments) must be used.

I.D.2. By the shell \$VARIABLE

Substitution by the shell - or by the windows command interpreter - uses backslash dollar sign. The next two sections explain why both punctuation marks are required, and then provide an example.

I.D.2.a Protecting shell variables

Because Perl variables look a lot like shell variables, you need to specially protect shell variables if you want to prevent Perl from trying to interpret them. Notice what happens with the protected and unprotected versions:

$ cat tmp.cfg
runlist              = mcf
size                 = test
tune                 = base,peak
iterations           = 1

output_format        = asc
teeout               = 1
expand_notes         = 1
use_submit_for_speed = 1

default=peak=default=default:
submit = echo "home=$HOME; spec=$SPEC;" > /tmp/chan; $command

default=base=default=default:
submit = echo "home=\$HOME; spec=\$SPEC;" > /tmp/nui; $command
$ runspec --config=tmp > /dev/null
$ cat /tmp/chan
home=; spec=;
$ cat /tmp/nui
home=/home/chris; spec=/spec/cpu2006;
$ 

In the first submit command, $HOME and $SPEC were gobbled up by runspec. But since those are not the names of variables that can be interpolated, empty strings were the result. In the second command, the backslashes prevented runspec from interpreting the variables, so they were seen by the shell instead.

By default, submit is only applied to rate runs. In this example, we used it for a speed run as well, by setting

use_submit_for_speed = 1 

in the configuration file.

I.D.2.b Example: submitting to multiple nodes, SGI Origin 2000

Here is a more complex example which uses substitution by both runspec and by the shell (the lines will be concatenated before execution):

   submit0= let "NODE=$SPECCOPYNUM/2"; 
   submit1= export NODE=/hw/nodenum/\$NODE; 
   submit2= let "CPU=2*(($SPECCOPYNUM+1)/2)-$SPECCOPYNUM "; 
   submit3= export CPU; 
   submit4= /usr/sbin/dplace -place \$SPEC/submit.pf -mustrun $command

(Note that the above example originated on an SGI Origin system where the shell uses let and dplace and other commands that might not apply to your shell.) Let's walk through how it works.

First, runspec substitutes the current copy number for $SPECCOPYNUM, and then passes the above command to the shell which does the substitutions for CPU and NODE. This example originated on an SGI Origin 2000 system, where there are two CPUs per node. Suppose that runspec is about to submit the copy for copy number 17. In that case, the above lines effectively cause::

   submit0= let "NODE=$SPECCOPYNUM/2";      # i.e. 17, so NODE=8
   submit1= export NODE=/hw/nodenum/\$NODE;      # Now NODE=/hw/nodenum/8
   submit2= let "CPU=2*(($SPECCOPYNUM+1)/2)-$SPECCOPYNUM ";  # and CPU=1
   submit3= export CPU; 
   submit4= /usr/sbin/dplace                     # So we execute dplace
            -place \$SPEC/submit.pf              # using $SPEC/submit.pf
            -mustrun $command                    # and the expected command

The desired $command is run under the control of submit.pf, with $NODE=/hw/nodenum/8 and $CPU=1. Here are the contents of the placement file, submit.pf:

   memories 1 in topology physical near $NODE
   threads 1
   run thread 0 on memory 0 using cpu $CPU

An important note about the above submit command:

• $SPECCOPYNUM must be spelled exactly as it is in the examples above. It is a limitation of the tools that saying things like ${SPECCOPYNUM} just won't work.

I.D.3. By specmake: $(VARIABLE)

Variables with a dollar sign and parentheses, aka "round brackets", are substituted by specmake. For example:

    COMPILER_DIR=/usr/local/bin/
    CC=$(COMPILER_DIR)cc

For a more extensive example of variable substitution handled by specmake, see the SPEC CPU2000 example at www.spec.org/cpu2000/docs/example-advanced.cfg. Search that file for LIBS, and note the long comment which provides a walk-through of a complex substitution handled by specmake. Note: a CPU2006 version of that example will be provided at a later date; but the concepts, from the CPU2000 example, are expected to work in a similar fashion for CPU2006.

Deprecated feature alert: Although it is also possible to pass information to specmake using curly brackets: ${SPECMAKE}, this is not recommended. Instead, you should consistently use curly brackets to address runspec and round brackets to address specmake. It is possible that a future version of runspec may insist on interpolating curly brackets itself, rather than allowing specmake to do so.

I.D.4. Limitations on variable substitution

Once runspec hands control over to specmake or to the shell, the results of further substitution are invisible to runspec. For this reason, you can't say:

Wrong:

MYDIR         = /usr/gretchen/compilers
FC             = $(MYDIR)/f90
notes_comp_001 = compiler: $(FC)

However, there are a couple of ways to get around this restriction. The best way for global settings is to use the preprocessor:

%define MYDIR /usr/gretchen/compilers
FC             = %{MYDIR}/f90
notes_comp_001 = compiler: %{MYDIR}/f90

That leaves a little to be desired, though, doesn't it? If your Fortran compiler is changed to 'f2001', you still need to remember to change it in two places. You could of course define a whole macro for this:

%define MYFC /usr/gretchen/compilers/f90
FC             = %{MYFC}
notes_comp_001 = compiler: %{MYFC}

But what if you have a config file where FC might be set in multiple places, and you really want to know how it was set right here? In that case, use a combination of the preprocessor and variable substitution:

$ cat right_here.cfg 
%define MYDIR /usr/gretchen/compilers

default=base:
FC              = %{MYDIR}/f2001
notes_comp_001  = For base, we used this Fortran: $[FC] 

410.bwaves=peak:
FC             = %{MYDIR}/f77
notes_comp_002 = For 410.bwaves peak, we used this Fortran: $[FC]

$ runspec -c right_here.cfg --fakereportable fp | grep txt       
        format: ASCII -> /usr/gretchen/spec/result/CFP2006.179.txt
$ tail -15 ../result/*179.txt

                          Compiler Invocation Notes
                          -------------------------
     For base, we used this Fortran: /usr/gretchen/compilers/f2001 
     For 410.bwaves peak, we used this Fortran: /usr/gretchen/compilers/f77

    SPEC and SPECfp are registered trademarks of the Standard Performance
    Evaluation Corporation.  All other brand and product names appearing
    in this result are trademarks or registered trademarks of their
    respective holders.
-----------------------------------------------------------------------------
For questions about this result, please contact the tester.
For other inquiries, please contact webmaster@spec.org.
Copyright 2006 Standard Performance Evaluation Corporation
Generated on Wed Aug  2 09:39:53 2006 by SPEC CPU2006 ASCII formatter v4626
$ 

I.D.5. Unsetting a variable with "%undef%"

It is sometimes useful to be able to undo the setting of a variable that is defined in a lower-precedence section. This is easily accomplished using the special value '%undef%':

  $ cat gnana.cfg
   teeout = yes
   action = build
   runlist = bzip2

   default=default:
   OPTIMIZE = -O
   COPTIMIZE = -fast

   401.bzip2=peak:
   COPTIMIZE = %undef%

   $ runspec --config=gnana --tune=base | grep bzip2.c
   cc -c -o bzip2.o -DSPEC_CPU -DNDEBUG   -O -fast                bzip2.c
   $ runspec --config=gnana --tune=peak | grep bzip2.c
   cc -c -o bzip2.o -DSPEC_CPU -DNDEBUG   -O                 bzip2.c
   $ go bzip
   /spec/gnana/kit91/benchspec/CPU2006/401.bzip2
   $ cd run/build_peak_none.0000/
   $ grep OPT Make*
   Makefile.spec:COPTIMIZE        = 
   Makefile.spec:OPTIMIZE         = -O

As you can see in the peak compilation, the '-fast' flag was not present because the setting for COPTIMIZE had been deleted.

II. Config file options for runspec

This section documents options that control the operation of runspec itself.

II.A. Precedence: config file vs. runspec command line

In the list that follows, some items are linked to runspec.html, because they can be specified either in a config file, or on the runspec command line.

If options can be specified on both the runspec command line and in a config file, the command line will win vs. items specified in the header section, but will not win over items specified in named sections. Effectively, the order of precedence is:

   named sections (highest)
   command line
   header section (lowest)

For an example of these precedence rules in action, see section VI.E. on --feedback

II.B. Options

In the table that follows, the "Use In" column indicates where the option can be used:

bind = 0,1,2,3,4,5,6,7, 16,17,18,19,20,21,22,23     

bind = <<EOT
0,   1,   2,   3,   4,   5,   6,   7,
16, 17,  18,  19,  20,  21,  22,  23        
EOT

bindN = string 

bind0 = taskset -c 1 
bind1 = taskset -c 0 
bind2 = taskset -c 0 
bind3 = taskset -c 0 

submit    = $BIND $command

benchspec/CPU2006/nnn.benchmark/build/build... (Unix) or
benchspec\CPU2006\nnn.benchmark\build\build... (Windows)

benchspec/CPU2006/nnn.benchmark/run/build... (Unix)
benchspec\CPU2006\nnn.benchmark\run\build... (Windows)

$ ls -l bwaves_base.tmp3
-rwxrwxr-x  1 david ptg 304964 May 16 9:16 bwaves_base.tmp
$ ldd bwaves_base.tmp | head -3
       libmvec.so.1 =>  /lib/libmvec.so.1
       libfui.so.2 =>   (file not found)
       libfai.so.3 =>   (file not found)
$ 

check_md5=0
env_vars=1
410.bwaves:
ENV_LD_LIBRARY_PATH=/spec/david/lovecraft/lib

400.perlbench=default:
#> I am posting this config file for use by others in the
#> company, but am forcing it to fail here because
#> I want to force users to review this section.
#>
#> Once you find your way here, you should test whether
#> bug report 234567 has been fixed, by using the first
#> line below.  If it has not been fixed, then use the
#> second.  In either case, you'll need to remove the
#> fail_build.
#>
#>   - Pney Guvaxre
#>     Boomtime, the 66th day of Confusion in the YOLD 3172

# OPTIMIZE = -Osuperduper
# OPTIMIZE = -Omiddling
fail_build = 1

http_proxy = http://webcache.tom.spokewrenchdad.com:8080 

$ cat -n tmp.cfg
     1  iterations = 1
     2  size       = test
     3  teeout     = yes
     4
     5  default=default:
     6  OPTIMIZE = -xO1 
     7
     8  int=default:
     9  OPTIMIZE = -xO2
    10  LIBS     = -lbsdmalloc
    11
    12  401.bzip2=default:
    13  OPTIMIZE = -xO3 
    14  CC = /update1/cc
    15
    16  458.sjeng=peak:
    17  inherit_from = 401.bzip2:default:default:default
    18  CC = /update2/cc
$ runspec --config tmp --tune base sjeng | grep sjeng.o
cc -c -o sjeng.o -DSPEC_CPU -DNDEBUG   -xO2        sjeng.c
cc  -xO2       attacks.o book.o ...  -lbsdmalloc  -o sjeng
$ runspec --config tmp --tune peak sjeng | grep sjeng.o
/update2/cc -c -o sjeng.o -DSPEC_CPU -DNDEBUG -xO3 sjeng.c
/update2/cc -xO3 attacks.o book.o ... -lbsdmalloc -o sjeng

   mailto=fast.guy@welovebenchmarks.org
   output_format=text,mail

   mailto=fast.guy@welovebenchmarks.org
   output_format=text,mail
   mail_reports=text