Despliegue

Además de definir cálculos, TFF proporciona herramientas para ejecutarlos. Mientras que el enfoque principal está en las simulaciones, las interfaces y herramientas que proporcionamos son más generales. Este documento describe las opciones de implementación en varios tipos de plataforma.

Descripción general

Hay dos modos principales de implementación para los cálculos TFF:

  • Motores nativos . Nos referiremos a un backend como nativo si es capaz de interpretar la estructura sintáctica de los cálculos TFF como se define en computation.proto . Un backend nativo no necesariamente tiene que admitir todas las construcciones o elementos intrínsecos del lenguaje. Los backends nativos deben implementar una de las interfaces de ejecutor TFF estándar, como tff.framework.Executor para el consumo mediante código Python, o la versión independiente del lenguaje definida en executor.proto expuesta como un punto final gRPC.

    Los backends nativos que admiten las interfaces anteriores se pueden usar de forma interactiva en lugar del tiempo de ejecución de referencia predeterminado, por ejemplo, para ejecutar cuadernos o scripts de experimentos. La mayoría de los servidores nativos operarán en modo interpretado , es decir, procesarán la definición de cálculo tal como está definida y la ejecutarán de forma incremental, pero este no siempre tiene que ser el caso. Un backend nativo también puede transformar ( compilar o compilar JIT) una parte del cálculo para mejorar el rendimiento o simplificar su estructura. Un ejemplo de uso común de esto sería reducir el conjunto de operadores federados que aparecen en un cálculo, de modo que partes del backend de la transformación no tengan que estar expuestas al conjunto completo.

  • Backends no nativos . Los backends no nativos, a diferencia de los nativos, no pueden interpretar directamente la estructura de cálculo de TFF y requieren que se convierta en una representación de destino diferente que comprenda el backend. Un ejemplo notable de este tipo de backend sería un clúster Hadoop o una plataforma similar para canalizaciones de datos estáticos. Para que un cálculo se implemente en dicho backend, primero debe transformarse (o compilarse ). Dependiendo de la configuración, esto se puede hacer de forma transparente para el usuario (es decir, un backend no nativo podría incluirse en una interfaz de ejecutor estándar como tff.framework.Executor que realiza transformaciones bajo el capó), o puede exponerse como una herramienta que permite al usuario convertir manualmente un cálculo, o un conjunto de cálculos, en la representación de destino adecuada entendida por la clase particular de backends. El código que admite tipos específicos de backends no nativos se puede encontrar en el espacio de nombres tff.backends . Al momento de escribir este artículo, el único tipo de soporte para backends no nativos es una clase de sistemas capaces de ejecutar MapReduce de una sola ronda.

Motores nativos

Más detalles próximamente.

Backends no nativos

Mapa reducido

Más detalles próximamente.