Отладка проблем с X10

Серверная часть ускорителя X10 может обеспечить значительно более высокую пропускную способность для параллельных вычислений на основе графов, но его отложенная трассировка и своевременная компиляция иногда могут приводить к неочевидному поведению. Это может включать в себя частую перекомпиляцию трассировок из-за изменений формы графа или тензора или огромные графики, которые приводят к проблемам с памятью во время компиляции.

Один из способов диагностики проблем — использовать метрики выполнения и счетчики, предоставляемые X10. Первое, что нужно проверить, если модель работает медленно, — это создать отчет о метриках.

Метрики

Чтобы распечатать отчет о показателях, добавьте в свою программу вызов PrintX10Metrics() :

import TensorFlow

...
PrintX10Metrics()
...

Это позволит регистрировать различные метрики и счетчики на уровне INFO .

Понимание отчета о показателях

Отчет включает в себя такие вещи, как:

  • Сколько раз мы запускаем компиляцию XLA и общее время, потраченное на компиляцию.
  • Сколько раз мы запускаем XLA-вычисление и общее время, потраченное на выполнение.
  • Сколько дескрипторов данных устройства мы создаем/уничтожаем и т. д.

Эта информация представлена ​​в виде процентилей выборок. Пример:

Metric: CompileTime
  TotalSamples: 202
  Counter: 06m09s401ms746.001us
  ValueRate: 778ms572.062us / second
  Rate: 0.425201 / second
  Percentiles: 1%=001ms32.778us; 5%=001ms61.283us; 10%=001ms79.236us; 20%=001ms110.973us; 50%=001ms228.773us; 80%=001ms339.183us; 90%=001ms434.305us; 95%=002ms921.063us; 99%=21s102ms853.173us

Мы также предоставляем счетчики, называемые целочисленными переменными, которые отслеживают внутреннее состояние программного обеспечения. Например:

Counter: CachedSyncTensors
  Value: 395

Известные предостережения

Tensor , поддерживаемый X10, семантически ведет себя как режим Tensor по умолчанию. Однако есть некоторые предостережения по поводу производительности и полноты:

  1. Снижение производительности из-за слишком большого количества перекомпиляций.

    Компиляция XLA стоит дорого. X10 автоматически перекомпилирует график каждый раз, когда встречаются новые фигуры, без вмешательства пользователя. Модели должны видеть стабилизированные формы в течение нескольких этапов обучения, и с этого момента перекомпиляция не требуется. Кроме того, пути выполнения должны быстро стабилизироваться по той же причине: X10 перекомпилируется при обнаружении нового пути выполнения. Подводя итог, чтобы избежать перекомпиляции:

    • Избегайте сильно изменчивых динамических форм. Тем не менее, небольшое количество различных форм может быть приемлемым. Приведите тензоры к фиксированным размерам, если это возможно.
    • Избегайте циклов с разным количеством итераций между этапами обучения. X10 в настоящее время разворачивает циклы, поэтому разное количество итераций цикла приводит к разным (развернутым) путям выполнения.

  2. Небольшое количество операций пока не поддерживается X10.

    В настоящее время у нас есть несколько операций, которые не поддерживаются либо потому, что нет хорошего способа выразить их через XLA и статические фигуры (в настоящее время только nonZeroIndices ), либо из-за отсутствия известных вариантов использования (несколько операций линейной алгебры и многочленная инициализация). . В то время как вторую категорию легко решить при необходимости, первую категорию можно решить только за счет совместимости с ЦП, а не с реализацией XLA. Слишком частое использование совместимости приводит к значительным последствиям для производительности из-за повторного обращения к хосту и фрагментации полностью объединенной модели в нескольких трассировках. Поэтому пользователям рекомендуется избегать использования таких операций в своих моделях.

    В Linux используйте XLA_SAVE_TENSORS_FILE (описано в следующем разделе), чтобы получить трассировку стека Swift, которая вызвала неподдерживаемую операцию. Имена функций можно разобрать вручную с помощью swift-demangle .

Получение и графическое отображение трассировок

Если вы подозреваете, что существуют проблемы со способом трассировки графиков, или хотите понять процесс трассировки, предоставляются инструменты для выхода из системы и визуализации трассировок. Вы можете заставить X10 журналировать найденные им следы, установив переменную среды XLA_SAVE_TENSORS_FILE :

export XLA_SAVE_TENSORS_FILE=/home/person/TraceLog.txt

Эти журналы трассировки имеют три формата: text , hlo и dot , причем формат устанавливается с помощью переменной среды XLA_SAVE_TENSORS_FMT:

export XLA_SAVE_TENSORS_FMT=text

Когда вы запускаете приложение, в text представлении, которое отключено, будет отображаться каждая отдельная трасса в текстовой нотации высокого уровня, используемой X10. Представление hlo показывает промежуточное представление, которое передается компилятору XLA. Возможно, вы захотите ограничить количество итераций в циклах обучения или вычислений, чтобы предотвратить слишком большой размер этих журналов. Кроме того, каждый запуск вашего приложения будет добавляться в этот файл, поэтому вы можете удалить его между запусками.

Установка переменной XLA_LOG_GRAPH_CHANGES в значение 1 также будет указывать в журнале трассировки, где произошли изменения в графике. Это чрезвычайно полезно при поиске мест, где может возникнуть перекомпиляция.

Для визуального представления трассы опция dot отключит графики, совместимые с Graphviz. Если вы извлечете часть трассы, которая выглядит как

digraph G {
    ...
}

в отдельный файл, Graphviz (при условии, что он установлен) может генерировать визуальную диаграмму через

dot -Tpng trace.dot -o trace.png

Обратите внимание, что установка переменной среды XLA_SAVE_TENSORS_FILE , особенно при использовании в сочетании с XLA_LOG_GRAPH_CHANGES , окажет существенное негативное влияние на производительность. Используйте их только при отладке, а не для обычной работы.

Дополнительные переменные среды

Дополнительные переменные среды для отладки включают:

  • XLA_USE_BF16 : если установлено значение 1, все значения Float преобразуются в BF16. Следует использовать только для отладки, поскольку мы предлагаем автоматическую смешанную точность.

  • XLA_USE_32BIT_LONG : если установлено значение 1, тип S4TF Long сопоставляется с 32-битным целочисленным типом XLA. В TPU 64-битные целочисленные вычисления требуют больших затрат, поэтому установка этого флага может помочь. Конечно, пользователь должен быть уверен, что значения по-прежнему укладываются в 32-битное целое число.