迭代轨迹数据step_trace_*.json,根据Iteration的长短,判断哪个迭代耗时最长。单算子场景(如PyTorch场景)下无此性能数据文件。
step_trace_*.json文件内容格式示例如下:
关键字段说明参见表1:
字段名 |
字段含义 |
---|---|
Title |
选择某个组件的接口名称。例如本例选择的为Model ID:6的FP_BP Time 5接口。 |
Start |
显示界面中时间轴上的时刻点,chrome trace自动对齐,单位ms。 |
Wall Duration |
表示当前接口调用耗时,单位ms。 |
Iteration ID |
以Graph为粒度统计的迭代ID,每个Graph执行一次,Iteration ID加1,当一个脚本被编译为多个Graph时,该ID与脚本层面的Step ID不一致。 |
FP Start |
FP开始时间,单位ns。 |
Iteration End |
每轮迭代结束时间,单位ns。 |
Iteration Time(ns) |
迭代耗时,单位ns。 |
BP End |
BP结束时间,单位ns。 |
FP_BP Time |
FP/BP计算耗时(BP End - FP Start),单位ns。 |
Iteration Refresh |
迭代更新拖尾耗时(Iteration End - BP End)。 |
Data_aug Bound |
数据增强拖尾耗时(本轮迭代FP Start - 上一个迭代Iteration End)。如果计算第一轮数据增强拖尾时没有上一轮迭代的Iteration End数据,那么第一轮迭代的数据增强拖尾数据值默认为N/A。 |
Reduce |
集合通信耗时,可能存在多组集合通信耗时(ph:B 表示某一组的开始时间,ph:E表示该组的结束时间);如果非多P环境,则没有Reduce数据。 |
注:离线推理场景下不采集FP(训练网络迭代轨迹正向算子的开始位置)和BP(训练网络迭代轨迹反向算子的结束位置),采集结果将显示FP Start、BP End为NA且不存在timeline。 |
对于前一个迭代结束到后一个迭代开始之间的迭代间隙,若因数据读取耗时较长导致间隙过大,可以通过GetNext时间片,判断是否由于迭代的数据读取时间较长导致间隙过大。如图1所示。
仅TensorFlow框架支持。
字段名 |
字段含义 |
---|---|
GetNext Start |
数据读取开始时间,单位ns。 |
GetNext End |
数据读取结束时间,单位ns。 |
GetNext Time(ns) |
数据读取耗时,单位ns。 |