Acovea

Application Configuration Files



 

Downloads acovea-gtk-1.0.1.tar.gz libacovea-5.1.1.tar.gz libevocosm-3.1.0.tar.gz libcoyotl-3.1.0.tar.gz About Acovea Acovea Overview A GUI for Acovea: Acovea-GTK Configuration Files FAQ About the Genetic Algorithm Analyses Acovea 5.0, GCC 4.0, Opteron Acovea 5.0, GCC 4.0, Pentium 4 Acovea 5.0, GCC 3.4, Opteron Acovea 4.0, GCC 3.4, P4, AMD64 (May-04) Acovea 3.3, GCC 3.x, P4 (Dec-03) Licensing GNU General Public License (GPL) Commercial License

If you find this article useful, please consider supporting the author's free software efforts with a donation, no matter how small.

 

GCC Opteron gcc 3.4 gcc 3.4 (makefile)  gcc 3.4 (size) g++ 3.4 gcc 4.0 gcc 4.0 gfortran 4.0

GCC Pentium 4 gcc 3.4 g++ 3.4 gcc 4.0 g++ 4.0 gfortran 4.0

GCC Pentium 3 gcc 3.4 g++ 3.4 gfortran 4.0 General Example Makefile

 

At the heart of Acovea's analysis is the application configuration, or, just simply, an Acovea config. These XML files describe something to be optimized by Acovea.

Note: In the following discussion, the terms flag and option are interchangable and mean the same thing: the specification of a factor that Acovea is to analyze for effectiveness. In the case of a compiler, this would be an optimization flag; in the case of a codec, it might be a quantisation factor.

Writing a configuration file requires an in-depth understanding of the application under analysis. In the case of GCC, for example, you need to consider the interactions of a hundred different options. Some flags, like the -On family, imply other options; or, the presence of one option may preclude the use of another (e.g., -funroll-loops and -funroll-all-loops).

In some cases, you may want to test a specific subset of flags

Acovea only produces valid results when you define an effective set of flags in its configuration.

Since Acovea began life as a tool for studying the GNU compilers, the current configuration files tend to be biased toward that purpose. However, there is nothing to stop Acovea from evolving solutions for a variety of applications. Many algorithms involve "tuning options" that can be analyzed by Acovea. When developing Itzam, I used Acovea to determine the best settings for various algorithmic factors.

Therein lies the purpose of Acovea: Replacing guesswork with concrete answers.

The Header

An Acovea config has two main sections: A header, and a set of "flags" from which solution sets will be evolved. Here's an example of the header:

<?xml version="1.0"?>
<acovea_config>
    <acovea version="5.0.0" />
    <description value="gcc 3.4 Opteron (AMD64/x86_64)" />
    
    <quoted_options value="false" />

    <prime command="gcc"
          flags="-lrt -lm -std=gnu99 -O1 -march=opteron ACOVEA_OPTIONS -o ACOVEA_OUTPUT ACOVEA_INPUT" />

    <baseline description="-O1"
          command="gcc"
          flags="-lrt -lm -std=gnu99 -O1 -march=opteron -o ACOVEA_OUTPUT ACOVEA_INPUT" />

Starting with version 5.0, Acovea will track versions of the config files; future versions will handle older configuration formats. For now, the only format understood is version 5.0.0.

The description is simply display text explaining what the configuration is for. When quoted_options is "true", Acovea will treat all option sets as a single argument; otherwise, each option is a separate argument. The Makefile configuration sets this flag to "true", for example.

The prime entry is used during evolution; it provides the boilerplate into which Acovea inserts its solutions for testing. The command text is simply the executable name of the program to be run; flags contains fixed and replacable arguments. ACOVEA_OPTIONS will be replaced by a list of the flags enabled for a given solution; ACOVEA_INPUT is the input file given when beginning the analysis, and ACOVEA_OUTPUT is an internally-generated random file name that will be placed in the /tmp directory

All of the above entries are mandatory. The baseline entry is optional; it defines a non-evolved test to be run at the end of Acovea's work. The results of baselines runs will be compared against Acovea's evolved solutions.

Makefiles

Acovea includes an example of configuring for a Makefile, using these definitions:

    <quoted_options value="true" />

    <prime command="make"
           flags='-s -f ACOVEA_INPUT OUTPUT="ACOVEA_OUTPUT" SETTINGS="ACOVEA_OPTIONS"' />

The example Makefile looks like this:

# this line eliminates any extra spaces in OUTPUT
BUILD_THIS = $(OUTPUT)

$(BUILD_THIS) : huffbench.c
        gcc -lrt -lm -O1 -std=gnu99 $(SETTINGS) -o $(BUILD_THIS) huffbench.c

Flags

The flags section contains a set of options that comprise an Acovea solution. Each solution has a complete set of flags, with some enabled and others disabled. Only the enabled flags will be included in a test run for a given solution, using the prime definition.

    <flags>
    
        <flag type="simple" value="-funsafe-math-optimizations" />
        <flag type="enum"   value="-funroll-loops|-funroll-all-loops" />
        <flag type="tuning" value="-finline-limit" default="600" min="100"
                                 max="10000" step="100" separator="=" />

    </flags>

</acovea_config>

Flags come in three flavors: simple, enum, and tuning. A simple flag is either on or off, and has not arguments or parameters. An enum option has a current value selected from the | delimited list. Tuning flags have a current value, within the given range, that Acovea can evolve up or down.

That's all there is to an Acovea config file. The complexity isn't in knowing the XML format, but in knowing which options to include. The forthcoming GCC 4.1, for example, changes a lot of flags, and I'm still wading through them to build a config file around them.

If you develop an interesting config file, I'll be more than happy to host it here on Coyote Gulch.