XLA предоставляет возможность контролировать объем усилий, которые компилятор будет тратить на
- оптимизировать производительность во время выполнения и
- сделать так, чтобы программа «помещалась в память» (что имеет платформенно-зависимое значение)
Уровень оптимизации
Подобно флагам -O в gcc или clang, это поле позволяет пользователю влиять на объём работы компилятора по оптимизации времени выполнения. Его можно задать через поле optimize_level сообщения ExecutableBuildOptionsProto или через поле optimize_level сообщения ExecutionOptions.
Более низкие уровни оптимизации приведут к разному поведению различных проходов HLO, обычно выполняя меньше работы, или могут полностью отключить некоторые проходы HLO. Уровень оптимизации также может влиять на бэкэнд компилятора, поэтому точное влияние этого поля зависит от целевой платформы. Однако в качестве общего руководства в следующей таблице описывается ожидаемый общий эффект каждого значения:
| Уровень | Вариант использования |
|---|---|
| EFFORT_O0 | Самая быстрая компиляция, самое медленное время выполнения |
| EFFORT_O1 | Более быстрая компиляция с разумным временем выполнения |
| EFFORT_O2 | Строго приоритизировать время выполнения (подходит по умолчанию для производственных рабочих нагрузок) |
| EFFORT_O3 | Дорогостоящие или экспериментальные оптимизации |
Использовать в XLA:GPU
В XLA:GPU есть несколько проходов, которые мы отключаем по умолчанию, поскольку они значительно увеличивают время компиляции за счёт увеличения размера HLO. Для удобства мы объединяем их в параметр «Уровень оптимизации», так что установка optimize_level в значение O1 или выше приведёт к следующему поведению:
- Коллективы, обычно используемые для параллельной передачи данных, будут конвейеризированы. Это поведение также можно контролировать более детально, включая отдельные флаги.
-
xla_gpu_enable_pipelined_all_gather -
xla_gpu_enable_pipelined_all_reduce -
xla_gpu_enable_pipelined_reduce_scatter
-
- Развёртывание циклов while в два раза. Разрушает барьер цикла, что потенциально приводит к лучшему перекрытию вычислений и коммуникаций и уменьшению количества копий.
-
xla_gpu_enable_while_loop_double_buffering
-
- Планировщик скрытия задержек выполнит большую часть работы по сокрытию задержек связи.
-
xla_gpu_enable_latency_hiding_scheduler
-
- Для максимизации пропускной способности сети проходы комбинатора объединяют конвейерные коллективы, используя максимально доступный объём памяти. Оптимизация не срабатывает, если цикл уже развёрнут во входном HLO.
Уровень подгонки памяти
Другой параметр уровня усилий определяет, в какой степени компилятор будет пытаться уместить результирующую программу в память, где «уместить» и «память» имеют значения, зависящие от бэкенда (например, в XLA:TPU этот параметр определяет, в какой степени компилятор старается поддерживать использование высокоскоростной памяти (HBM) TPU ниже ёмкости HBM). Его можно задать через поле memory_fitting_level сообщения ExecutableBuildOptionsProto или поле memory_fitting_level сообщения ExecutionOptions.
Как и в случае с уровнем оптимизации, точное значение каждого уровня усилий зависит от бэкэнда, но в следующей таблице в качестве общего руководства описывается ожидаемый эффект:
| Уровень | Вариант использования |
|---|---|
| EFFORT_O0 | Минимальные усилия для подгонки (вместо этого проваливайте компиляцию как можно быстрее) |
| EFFORT_O1 | Меньше усилий для установки |
| EFFORT_O2 | Значительные усилия по установке (подходит по умолчанию для производственных рабочих нагрузок) |
| EFFORT_O3 | Дорогие или экспериментальные алгоритмы для уменьшения использования памяти |