Уровни усилий

XLA предоставляет возможности для управления объемом усилий, которые компилятор будет затрачивать на...

• оптимизировать производительность во время выполнения, и
• чтобы программа "поместилась в память" (что имеет значение, зависящее от платформы).

Уровень оптимизации

Подобно флагам -O в gcc или clang, это поле позволяет пользователю влиять на объем работы, которую компилятор выполняет по оптимизации времени выполнения. Его можно установить через поле optimization_level сообщения ExecutableBuildOptionsProto или через поле optimization_level сообщения ExecutionOptions.

Более низкие уровни оптимизации приведут к тому, что различные проходы HLO будут вести себя по-разному, как правило, выполняя меньше работы, или могут полностью отключить некоторые проходы HLO. Уровень оптимизации также может влиять на бэкэнд компилятора, поэтому точное влияние этого поля зависит от целевой платформы. Однако, в качестве общего руководства, в следующей таблице описано ожидаемое общее влияние каждого значения:

Использовать в XLA:GPU

Конвейерная обработка может быть настроена отдельно для режимов all-gather, all-reduce и reduce-scatter. Флаги xla_gpu_pipeline_all_gather , xla_gpu_pipeline_all_reduce и xla_gpu_pipeline_reduce_scatter принимают default , off , on или explicit . Значение default соответствует уровню оптимизации: оно on при O1 или выше, или когда уровень оптимизации во время выполнения составляет не менее 0,2; в противном случае оно включается off . Любой другой режим переопределяет уровень оптимизации. Для режимов all-gather и all-reduce по default используется значение default, а для reduce-scatter — значение on . См. раздел «Флаги GPU XLA» для получения информации о семантике режимов.

В XLA:GPU есть несколько проходов, которые мы отключаем по умолчанию, поскольку они значительно увеличивают время компиляции за счет увеличения размера HLO. Для удобства мы объединили их в параметре уровня оптимизации, так что установка optimization_level на O1 или выше приведет к следующему поведению:

• Коллективная конвейерная обработка по умолчанию on для операций, обычно используемых для параллельной передачи данных. Режимы off и explicit по-прежнему переопределяют это значение по умолчанию.
  • xla_gpu_pipeline_all_gather
  • xla_gpu_pipeline_all_reduce
  • xla_gpu_pipeline_reduce_scatter
• Развертывание циклов while в два раза увеличивает их количество. Это преодолевает барьер циклов, потенциально приводя к лучшему совпадению вычислительных и коммуникационных ресурсов и уменьшению количества копий.
  • xla_gpu_enable_while_loop_double_buffering
• Планировщик, скрывающий задержку, выполнит большую часть работы по скрытию задержки связи.
  • xla_gpu_enable_latency_hiding_scheduler
• Для максимизации пропускной способности сети проходы сумматора будут объединять конвейерные коллективные операции в максимально доступный объем памяти. Оптимизация не запускается, если цикл уже развернут во входном HLO.
  • all_gather_combiner
  • all_reduce_combiner
  • reduce_scatter_combiner

Уровень соответствия памяти

Ещё один параметр уровня сложности определяет, насколько сильно компилятор будет пытаться «поместить» результирующую программу в память, причём значения «поместить» и «память» зависят от бэкенда (например, в XLA:TPU этот параметр определяет, насколько сильно компилятор будет работать над тем, чтобы использование высокоскоростной памяти (HBM) TPU оставалось ниже её максимальной ёмкости). Его можно установить через поле memory_fitting_level сообщения ExecutableBuildOptionsProto или через поле memory_fitting_level сообщения ExecutionOptions.

Как и в случае с уровнем оптимизации, точное значение каждого уровня усилий зависит от бэкэнда, но в следующей таблице в качестве общего ориентира описан ожидаемый эффект: