浏览代码

Profiling docs (#2325)

* profiling docs

* clean up debug option, move csv info

* Imitation Learning -> Behavioral Cloning
/develop-generalizationTraining-TrainerController
GitHub 5 年前
当前提交
9fc0c465
共有 2 个文件被更改,包括 67 次插入4 次删除
  1. 18
      docs/Training-ML-Agents.md
  2. 53
      docs/Profiling.md

18
docs/Training-ML-Agents.md


training doesn't involve visual observations (reading from Pixels). See
[here](https://docs.unity3d.com/Manual/CommandLineArguments.html) for more
details.
* `--debug` - Specify this option to run ML-Agents in debug mode and log Trainer
Metrics to a CSV stored in the `summaries` directory. The metrics stored are:
brain name, time to update policy, time since start of training, time for last experience collection, number of experiences used for training, mean return. This
option is not available currently for Imitation Learning.
* `--debug` - Specify this option to enable debug-level logging for some parts of the code.
### Training config file

to the corresponding sections of the `config/trainer_config.yaml` file for each
example to see how the hyperparameters and other configuration variables have
been changed from the defaults.
### Output metrics
Trainer Metrics are logged to a CSV stored in the `summaries` directory. The metrics stored are:
* brain name
* time to update policy
* time since start of training
* time for last experience collection
* number of experiences used for training
* mean return
This option is not available currently for Behavioral Cloning.
[Profiling](Profiling.md) information is also saved in the `summaries` directory.

53
docs/Profiling.md


# Profiling ML-Agents in Python
ML-Agents provides a lightweight profiling system, in order to identity hotspots in the training process and help spot
regressions from changes.
Timers are hierarchical, meaning that the time tracked in a block of code can be further split into other blocks if
desired. This also means that a function that is called from multiple places in the code will appear in multiple
places in the timing output.
All timers operate using a "global" instance by default, but this can be overridden if necessary (mainly for testing).
## Adding Profiling
There are two ways to indicate code should be included in profiling. The simplest way is to add the `@timed`
decorator to a function or method of interested.
```python
class TrainerController:
# ....
@timed
def advance(self, env: EnvManager) -> int:
# do stuff
```
You can also used the `hierarchical_timer` context manager.
``` python
with hierarchical_timer("communicator.exchange"):
outputs = self.communicator.exchange(step_input)
```
The context manager may be easier than the `@timed` decorator for profiling different parts of a large function, or
profiling calls to abstract methods that might not use decorator.
## Output
By default, at the end of training, timers are collected and written in json format to
`{summaries_dir}/{run_id}_timers.json`. The output consists of node objects with the following keys:
* name (string): The name of the block of code.
* total (float): The total time in seconds spent in the block, including child calls.
* count (int): The number of times the block was called.
* self (float): The total time in seconds spent in the block, excluding child calls.
* children (list): A list of child nodes.
* is_parallel (bool): Indicates that the block of code was executed in multiple threads or processes (see below). This
is optional and defaults to false.
### Parallel execution
For code that executes in multiple processes (for example, SubprocessEnvManager), we periodically send the timer
information back to the "main" process, aggregate the timers there, and flush them in the subprocess. Note that
(depending on the number of processes) this can result in timers where the total time may exceed the parent's total
time. This is analogous to the difference between "real" and "user" values reported from the unix `time` command. In the
timer output, blocks that were run in parallel are indicated by the `is_parallel` flag.
正在加载...
取消
保存