Depuración de problemas de X10

El backend del acelerador X10 puede proporcionar un rendimiento significativamente mayor para el cálculo paralelo basado en gráficos, pero su seguimiento diferido y su compilación justo a tiempo pueden conducir a veces a un comportamiento no obvio. Esto podría incluir la recompilación frecuente de trazas debido a cambios en la forma del tensor o gráfico, o gráficos enormes que provocan problemas de memoria durante la compilación.

Una forma de diagnosticar problemas es utilizar las métricas y contadores de ejecución proporcionados por X10. Lo primero que se debe comprobar cuando un modelo es lento es generar un informe de métricas.

Métrica

Para imprimir un informe de métricas, agregue una llamada PrintX10Metrics() a su programa:

import TensorFlow

...
PrintX10Metrics()
...

Esto registrará varias métricas y contadores a nivel INFO .

Comprender el informe de métricas

El informe incluye cosas como:

  • Cuántas veces activamos compilaciones XLA y el tiempo total dedicado a la compilación.
  • Cuántas veces lanzamos un cálculo XLA y el tiempo total empleado en su ejecución.
  • Cuántos datos del dispositivo manejamos creamos/destruimos, etc.

Esta información se reporta en términos de percentiles de las muestras. Un ejemplo es:

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

También proporcionamos contadores, que son variables enteras denominadas que rastrean el estado del software interno. Por ejemplo:

Counter: CachedSyncTensors
  Value: 395

Advertencias conocidas

Tensor respaldados por X10 se comportan semánticamente como los Tensor en modo ansioso predeterminados. Sin embargo, existen algunas advertencias sobre el rendimiento y la integridad:

  1. Rendimiento degradado debido a demasiadas recompilaciones.

    La compilación XLA es cara. X10 vuelve a compilar automáticamente el gráfico cada vez que se encuentran nuevas formas, sin intervención del usuario. Los modelos necesitan ver formas estabilizadas en unos pocos pasos de entrenamiento y, a partir de ese punto, no es necesario volver a compilarlos. Además, las rutas de ejecución deben estabilizarse rápidamente por la misma razón: X10 se vuelve a compilar cuando se encuentra una nueva ruta de ejecución. En resumen, para evitar recompilaciones:

    • Evite formas dinámicas muy variables. Sin embargo, un número reducido de formas diferentes podría estar bien. Rellene los tensores con tamaños fijos cuando sea posible.
    • Evite bucles con diferente número de iteraciones entre los pasos de entrenamiento. Actualmente, X10 desenrolla bucles, por lo tanto, un número diferente de iteraciones de bucle se traduce en diferentes rutas de ejecución (desenrolladas).

  2. X10 aún no admite una pequeña cantidad de operaciones.

    Actualmente tenemos un puñado de operaciones que no son compatibles, ya sea porque no hay una buena manera de expresarlas mediante XLA y formas estáticas (actualmente solo nonZeroIndices ) o por falta de casos de uso conocidos (varias operaciones de álgebra lineal e inicialización multinomial) . Si bien la segunda categoría es fácil de abordar según sea necesario, la primera categoría solo se puede abordar mediante la interoperabilidad con la CPU, implementación que no sea XLA. El uso de la interoperabilidad con demasiada frecuencia tiene importantes implicaciones en el rendimiento debido a los viajes de ida y vuelta del host y a la fragmentación de un modelo completamente fusionado en múltiples rastros. Por lo tanto, se recomienda a los usuarios que eviten utilizar este tipo de operaciones en sus modelos.

    En Linux, use XLA_SAVE_TENSORS_FILE (documentado en la siguiente sección) para obtener el seguimiento de la pila Swift que llamó a la operación no admitida. Los nombres de las funciones se pueden exigir manualmente usando swift-demangle .

Obtención y graficación de trazas.

Si sospecha que hay problemas con la forma en que se rastrean los gráficos o desea comprender el proceso de rastreo, se proporcionan herramientas para cerrar sesión y visualizar los rastreos. Puede hacer que X10 cierre la sesión de los rastros que encuentre configurando la variable de entorno XLA_SAVE_TENSORS_FILE :

export XLA_SAVE_TENSORS_FILE=/home/person/TraceLog.txt

Estos registros de seguimiento vienen en tres formatos: text , hlo y dot , y el formato se puede configurar mediante la variable de entorno XLA_SAVE_TENSORS_FMT:

export XLA_SAVE_TENSORS_FMT=text

Cuando ejecuta su aplicación, la representación text en la que se cierra la sesión mostrará cada seguimiento individual en una notación de texto de alto nivel utilizada por X10. La representación hlo muestra la representación intermedia que se pasa al compilador XLA. Es posible que desee restringir el número de iteraciones dentro de sus ciclos de entrenamiento o cálculo para evitar que estos registros se vuelvan demasiado grandes. Además, cada ejecución de su aplicación se agregará a este archivo, por lo que es posible que desee eliminarlo entre ejecuciones.

Establecer la variable XLA_LOG_GRAPH_CHANGES en 1 también indicará dentro del registro de seguimiento dónde se han producido cambios en el gráfico. Esto es extremadamente útil para encontrar lugares donde se producirá la recompilación.

Para obtener una representación visual de un trazo, la opción dot cerrará la sesión de los gráficos compatibles con Graphviz. Si extraes la porción de un rastro que se parece

digraph G {
    ...
}

en su propio archivo, Graphviz (suponiendo que esté instalado) puede generar un diagrama visual a través de

dot -Tpng trace.dot -o trace.png

Tenga en cuenta que configurar la variable de entorno XLA_SAVE_TENSORS_FILE , especialmente cuando se usa en combinación con XLA_LOG_GRAPH_CHANGES , tendrá un impacto negativo sustancial en el rendimiento. Utilícelos únicamente durante la depuración y no para el funcionamiento normal.

Variables de entorno adicionales

Las variables de entorno adicionales para la depuración incluyen:

  • XLA_USE_BF16 : si se establece en 1, transforma todos los valores Float a BF16. Solo debe usarse para depurar, ya que ofrecemos precisión mixta automática.

  • XLA_USE_32BIT_LONG : si se establece en 1, asigna el tipo Long S4TF al tipo entero XLA de 32 bits. En TPU, los cálculos de enteros de 64 bits son costosos, por lo que configurar este indicador podría ayudar. Por supuesto, el usuario debe estar seguro de que los valores aún caben en un entero de 32 bits.