Skip to content

Fixed engine parameters

Tuning and its search space are a way of introducing and choosing from a set of possible values for various engine parameters. However, sometimes it is desired to add a parameter that is not subject to searching - i.e., it is always used with a specific, user-provided value. One such example could be adding a parameter that disables printing incoming requests anywhere.

Below, we discuss different ways of introducing such parameters and how they differ.

Dedicated YAML file

The preferred way of introducing a set of extra arguments is to specify them with a dedicated YAML file. For example, if a launch command should be extended with the following parameters: ENV_VAR=test python ... --foo=yes --bar, the structure of the file should be as below:

1
2
3
4
5
6
cli: # (1)!
    foo: yes # (2)!
    bar: null # (3)!

env: # (4)!
    ENV_VAR: test
  1. The cli part refers to command-line arguments.
  2. Note leading dashes -- are omitted from parameter names.
  3. For parameter-less flags, the value should be null (maps to Python None) or !present
  4. The env part refers to environmental variables. Note the values have to be convertible to strings.

The file with these additional arguments can then be passed to mako tune using the --extra-args parameter. See mako tune documentation. Even though this is the preferred way, please note the differences between different approaches and make sure to chose the one which works better for your case.

Singleton search space entry

Alternatively, a parameter can be included in the search space with only one possible value - by doing so the provided value will always be used.

In order to do, you will need to re-define the entire search space and add the extra argument(s). Following on the example above, the search space should be extended as below:

1
2
3
4
5
6
7
cli:
    ... # the search space as usual
    foo: [yes]
    bar: [null]

env:
    ENV_VAR: [test]

Warning

Due to how searching might be implemented, the above way of introducing extra argument is actually not guaranteed to always result in the extra arguments being added to the server. However, any trial that does not add them will also not be considered valid. See notes on auxiliary trials for details.

For more details on defining your own search spaces, see a dedicated page.

Differences

The main different between the two approaches above is whether the arguments are reported as part of the final solution. If they are included in the search space, they are considered important for performance and will be saved and reused with any mako serve command. On the other hand, if they are part of the extra arguments file, they will not be considered part of the solution and will not be subject to serving with mako serve.