Ayuda a proteger la Gran Barrera de Coral con TensorFlow en Kaggle Únete Challenge

Desarrollando un nuevo backend para XLA

Esta guía preliminar está destinada a los primeros usuarios que desean redirigir fácilmente TensorFlow a su hardware de manera eficiente. La guía no es paso a paso y asume el conocimiento de LLVM , Basel , y TensorFlow.

XLA proporciona una interfaz abstracta que una nueva arquitectura o acelerador puede implementar para crear un backend para ejecutar gráficos de TensorFlow. Reorientar XLA debería ser significativamente más simple y escalable que implementar cada TensorFlow Op existente para hardware nuevo.

La mayoría de las implementaciones caerán en uno de los siguientes escenarios:

  1. Arquitectura de la CPU existente aún no oficialmente soportado por XLA, con o sin una ya existente LLVM backend.
  2. Hardware no similar a una CPU con un backend LLVM existente.
  3. Hardware no similar a una CPU sin un backend LLVM existente.

Escenario 1: Arquitectura de CPU existente que aún no es compatible oficialmente con XLA

En este escenario, empezar por mirar el vigente backend XLA CPU . XLA facilita el redireccionamiento de TensorFlow a diferentes CPU mediante el uso de LLVM, ya que la principal diferencia entre los backends de XLA para CPU es el código generado por LLVM. Google prueba XLA para arquitecturas x64 y ARM64.

Si el proveedor de hardware tiene un backend LLVM para su hardware, es sencillo vincular el backend con el LLVM creado con XLA. En el modo JIT, el backend de la CPU XLA emite código para la CPU del host. Para la compilación antes de tiempo, xla::AotCompilationOptions pueden proporcionar una LLVM triples para configurar la arquitectura destino.

Si no existe un backend LLVM pero existe otro tipo de generador de código, debería ser posible reutilizar la mayor parte del backend de la CPU existente.

Escenario 2: hardware no similar a una CPU con un backend LLVM existente

Es posible modelar un nuevo xla::Compiler aplicación en el vigente xla::CPUCompiler y xla::GPUCompiler clases, puesto que ya emiten LLVM IR. Dependiendo de la naturaleza del hardware, es posible que muchos de los aspectos de generación de LLVM IR tengan que cambiarse, pero se puede compartir una gran cantidad de código con los backends existentes.

Un buen ejemplo a seguir es el back-end GPU de XLA. El backend de la GPU se dirige a un ISA que no es similar a una CPU y, por lo tanto, algunos aspectos de la generación de su código son exclusivos del dominio de la GPU. Otros tipos de hardware, por ejemplo, DSP como Hexagon (que tiene un backend LLVM ascendente), pueden reutilizar partes de la lógica de emisión IR de LLVM, pero otras partes serán únicas.

Escenario 3: hardware no similar a una CPU sin un backend LLVM existente

Si no es posible utilizar LLVM, la mejor opción es implementar un nuevo backend para XLA para el hardware deseado. Esta opción requiere el mayor esfuerzo. Las clases que deben implementarse son las siguientes:

  • StreamExecutor : Para muchos dispositivos no todos los métodos de StreamExecutor se necesitan. Ver existentes StreamExecutor implementaciones para obtener más detalles.
  • xla::Compiler : Esta clase encapsula la compilación de un cálculo objetivo de alto nivel en un xla::Executable .
  • xla::Executable : Esta clase se utiliza para poner en marcha un cálculo compilado en la plataforma.
  • xla::TransferManager : Esta clase permite backends para proporcionar mecanismos específicos de la plataforma para la construcción de XLA datos literales de asas memoria del dispositivo dado. En otras palabras, ayuda a encapsular la transferencia de datos desde el host al dispositivo y viceversa.