Entrevista: La promesa de Intel oneAPI y Direct Parallel C++

Intel no es el primer nombre que te viene a la mente cuando piensas en el desarrollo de software, a pesar de que es una de las empresas tecnológicas más influyentes e innovadoras del planeta. Hace cuatro décadas, el procesador 8088 de Intel ayudó a lanzar la revolución de las PC, y si está leyendo esto en una computadora de escritorio o portátil, es probable que tenga un Intel Inside. Lo mismo ocurre con los servidores y una gama de otro hardware en el que confiamos todos los días. Eso no quiere decir que AMD y otros proveedores no tengan productos competitivos porque los tienen, pero Intel aún domina el mercado de CPU x86.

Los ingenieros de software han estado utilizando plataformas de hardware de Intel durante décadas, por lo general sin siquiera considerar el software y el firmware detrás de ellas. Si necesitaban más rendimiento de virtualización, optaron por productos multinúcleo, Core i7 hiperproceso o Xeon. Para modificar la base de datos local, podrían obtener un SSD de Intel. Pero ahora, Intel quiere que los desarrolladores también comiencen a usar más de su software.

¿Qué es Intel oneAPI?

Ingrese oneAPI, promocionado por Intel como un modelo de programación único y unificado que tiene como objetivo simplificar el desarrollo en diferentes arquitecturas de hardware: CPU, GPU, FPGA, aceleradores de IA y más. Todos ellos tienen propiedades muy diferentes y sobresalen en diferentes tipos de operaciones.

Intel ahora está comprometida con una estrategia de "primero el software" y espera que los desarrolladores tomen nota. La gran idea detrás de oneAPI es permitir el uso de una plataforma para una variedad de hardware diferente, por lo que los desarrolladores no tendrían que usar diferentes lenguajes, herramientas y bibliotecas cuando codifican para CPU y GPU, por ejemplo. Con oneAPI, la caja de herramientas y el código base serían los mismos para ambos.

Para que esto sea posible, Intel desarrolló Data Parallel C++ (DPC++) como una alternativa de código abierto a los lenguajes propietarios que normalmente se usan para programar hardware específico (por ejemplo, GPU o FFPGA). Se supone que este nuevo lenguaje de programación ofrece la productividad y la familiaridad de C ++ al tiempo que incluye un compilador para implementar en diferentes objetivos de hardware.

Data Parallel C++ también incorpora SYCL de Khronos Group para admitir el paralelismo de datos y la programación heterogénea. Actualmente, Intel ofrece acceso gratuito a su DevCloud, lo que permite a los ingenieros de software probar sus herramientas y jugar con oneAPI y DPC++ en la nube sin muchos problemas.

Pero espere, ¿funcionará en hardware fabricado por otros proveedores? ¿Qué pasa con la licencia, es gratis? Sí y sí: oneAPI está diseñado para ser independiente del hardware y de código abierto, y eso no cambiará.

Para obtener más información sobre oneAPI, discutimos su génesis y futuro con Sanjiv M. Shah, vicepresidente del grupo de arquitectura, gráficos y software de Intel y gerente general de computación técnica, empresarial y en la nube de Intel.

Sanjiv: En términos de lo que hay en oneAPI, lo considero como cuatro piezas. Uno es un lenguaje y una biblioteca estándar, el segundo es un conjunto de herramientas de aprendizaje profundo, el tercero es realmente una capa de abstracción de hardware y una capa de controlador de software que puede abstraer diferentes aceleradores, y la cuarta pieza es un conjunto de bibliotecas centradas en el dominio. , como Matlab y así sucesivamente. Esas son las cuatro categorías de cosas en oneAPI, pero podemos profundizar más y hablar sobre los nueve elementos de oneAPI. Esos nueve elementos son básicamente el nuevo lenguaje que estamos presentando llamado Data Parallel C++ y su biblioteca estándar.

Hay dos bibliotecas de aprendizaje, una para redes neuronales y otra para comunicaciones. Está la biblioteca a la que llamamos nivel cero que es para la abstracción de hardware, y hay cuatro bibliotecas centradas en el dominio. Estamos haciendo esto de una manera muy, muy abierta. Las especificaciones para todos estos ya están abiertas y disponibles. Los llamamos versión 0.5. Tenemos la intención de conducir a 1.0 para fines de 2020, y también tenemos implementaciones de código abierto de todos estos. Una vez más, nuestro objetivo es permitir que las personas aprovechen lo que ya existe. Si un proveedor de hardware quiere implementar este lenguaje, puede tomar lo que es de código abierto y ejecutarlo.

P: Con respecto a los algoritmos y la implementación, ¿cómo funciona eso?

Lo que proporcionamos son las primitivas que usarían los algoritmos: las primitivas matemáticas subyacentes y las primitivas de comunicación. Por lo general, la innovación de algoritmos ocurre a un nivel más alto que ese, donde realmente no se están rehaciendo las matemáticas fundamentales, las matemáticas matriciales, las matemáticas de convolución, etc. Se trata de encontrar nuevas formas de usar esas matemáticas y nuevas formas de usar patrones de comunicación. Nuestro objetivo realmente es que proporcionemos lo primitivo, el nivel cero, para que otros puedan innovar por encima de eso.

P: ¿Cómo funciona a nivel de hardware?

Si usted es un proveedor de hardware, tomemos una matriz de IA, alguien que construye un ASIC de IA, por ejemplo: hay dos formas para que ese proveedor de hardware se “conecte” y aproveche el ecosistema de IA. Una sería proporcionar esta interfaz de hardware de bajo nivel que llamamos nivel cero, y si proporcionan su versión de nivel cero usando la API estándar, pueden aprovechar el código abierto si lo desean, y luego todas las capas de software anteriores. puede aprovechar eso automáticamente.

Eso podría ser difícil para un ASIC centrado en el segmento, para proporcionar la generalidad completa del nivel cero. Entonces, como alternativa a eso, también pueden proporcionar los núcleos matemáticos y los núcleos de comunicación que están en nuestro dominio y bibliotecas de aprendizaje profundo, y luego haremos el trabajo de "conectar" esas bibliotecas en los marcos de trabajo de nivel superior, por lo que obtendrían eso automáticamente.

P: Mencionó que la versión que tiene en este momento está designada como 0.5, y la especificación completa debería estar lista para fines de 2020.

Entonces, hay dos partes en nuestra iniciativa oneAPI. Una es la parte de la industria y la otra son los productos de Intel. La especificación de la industria está en 0,5 y, a mediados de año, nos gustaría llegar a 1,0. Paralelamente, Intel está construyendo un conjunto de productos, y los productos que Intel está construyendo están hoy en versión beta e implementan la especificación 0.5. Para fin de año, nos gustaría llegar a un producto 1.0.

El producto de Intel va más allá de los nueve elementos de oneAPI porque, además de los elementos básicos de programación que brindamos, también queremos brindar las cosas que los programadores realmente necesitan, como depuradores, analizadores y herramientas de compatibilidad para que migren de los lenguajes existentes a Data. Lenguaje C++ paralelo.

P: ¿Qué tan difícil es para el desarrollador hacer la transición? ¿Es el entorno más amplio similar al que han estado usando durante años?

Sí, es muy parecido. Permítanme describir un poco Data Parallel C++ porque eso es una gran parte de lo que estamos haciendo. DPC++ es tres cosas. Se basa en el lenguaje C++ del estándar internacional ISO. Hay un grupo llamado Khronos que define el estándar llamado SYCL, y SYCL se superpone a C++. Tomamos SYCL y luego agregamos extensiones encima de SYCL. La forma en que estamos construyendo Data Parallel C++, realmente es solo C++ con extensiones, que es SYCL.

Cualquier compilador de C++ puede compilarlo. La belleza de DPC ++ es que cualquier compilador puede compilarlo, solo un compilador experto puede aprovechar lo que hay en ese lenguaje y generar código acelerador. La forma en que manejamos este lenguaje, lo hacemos muy, muy abiertamente, por lo que todas nuestras discusiones sobre Data Parallel C++ se llevan a cabo con el comité SYCL. Las implementaciones son de código abierto, todas las extensiones ya están publicadas y estamos trabajando muy, muy cuidadosamente para asegurarnos de que tenemos un buen camino hacia los futuros estándares SYCL. Mirando hacia abajo a 5-10 años a partir de ahora, un camino de deslizamiento hacia ISO C ++ también.

P: Con respecto a los compiladores y la migración a DPC++, ¿la curva de aprendizaje no debería ser un gran problema?

Sí, depende de dónde empieces, por supuesto. Para un programador de C++, la curva de aprendizaje sería muy pequeña. Para un programador de C, tendría que superar el obstáculo de aprender C++, pero eso es todo. Es muy familiar C++. Para un programador acostumbrado a lenguajes como OpenCL, debería ser muy similar.

La otra parte que debo enfatizar es que estamos haciendo el trabajo en código abierto utilizando la infraestructura LLVM. Toda nuestra fuente ya está abierta, hay un repositorio Intel GitHub donde puede ir y ver la implementación del lenguaje, incluso descargar un compilador de fuente abierta. Todas las herramientas de Intel, nuestras ofertas de productos que son beta también están disponibles de forma gratuita para que cualquiera pueda jugar y descargar. También tenemos disponible una nube para desarrolladores, donde las personas no necesitan descargar ni instalar nada, solo pueden escribir el código y comenzar a usar todas las herramientas de las que hablamos.

P: C++ es eficiente y relativamente simple, pero todos sabemos que se está volviendo obsoleto, el desarrollo es lento, hay demasiadas partes interesadas, por lo que están ralentizando todo. Obviamente, este no sería el caso con DPC++. ¿Tendrías iteraciones y actualizaciones mucho más rápidas?

Creo que ha llegado a un punto muy, muy importante para nosotros, que es una evolución rápida que no se ve ralentizada por los estándares. Entonces, queremos discutir abiertamente con el estándar, para que haya una manera de entrar en los estándares, pero también queremos hacerlo rápidamente.

Los lenguajes funcionan mejor cuando están codiseñados por sus usuarios e implementadores, a medida que evolucionan las arquitecturas. Nuestro objetivo es un diseño de código iterativo realmente rápido donde estamos practicando cosas, encontrando la mejor manera de hacer las cosas y haciéndolas estándar. Entonces, absolutamente, la iteración rápida es un gran objetivo.

P: Una pregunta que plantearon algunos de mis colegas (probablemente comprenda que están algo preocupados por la apertura con cualquier cosa que venga de una gran corporación): ¿DPC++ permanecerá siempre abierto a todos los usuarios y proveedores?

¡Absolutamente! La especificación se realiza con una licencia creative commons. Cualquiera puede usar la especificación, tomarla y bifurcarla si quiere, y evolucionarla. Quiero enfatizar que no todos los elementos de oneAPI son de código abierto, pero estamos en camino de hacer que casi todos los elementos sean de código abierto. Todo eso, cualquiera puede tomarlo y aprovecharlo: está disponible para su implementación.

Codeplay, que es una empresa del Reino Unido, anunció una implementación de Nvidia de DPC++, y realmente estamos alentando a todos los proveedores de hardware y software a que hagan su port. Estamos en un punto único en la industria donde los aceleradores se están volviendo comunes para múltiples proveedores. Cuando eso sucede en la historia, cuando solo hay un proveedor, su idioma domina. La industria del software demanda una solución estándar y múltiples proveedores.

Lo que estamos tratando de hacer aquí es lo que hicimos hace aproximadamente dos décadas y media con OpenMP, donde había múltiples lenguajes paralelos pero ninguno realmente dominante. Tomamos todo eso y lo unificamos en un estándar que ahora, 25 años después, es la manera de programar HPC.

P: ¿Sería correcto decir que DPC++ experimentará una gran evolución en los próximos años? ¿Qué pasa con los tensores, qué pasa con el nuevo hardware que sale?

Sí, absolutamente, tienes razón. Tenemos que hacer evolucionar el lenguaje para soportar el nuevo hardware que está saliendo. Ese es el objetivo de una iteración más rápida. Otro punto que quiero enfatizar es que estamos diseñando Data Parallel C++ para que también pueda conectar extensiones específicas de la arquitectura si lo desea.

Entonces, si bien es un lenguaje estándar que queremos ejecutar en múltiples arquitecturas, también nos damos cuenta de que, a veces, una audiencia, una audiencia muy importante, necesita el máximo rendimiento posible. Es posible que deseen sumergirse en la programación de muy bajo nivel que no necesariamente será compatible con la arquitectura. Estamos construyendo extensiones y mecanismos para que pueda tener extensiones para tensores, etc., que serían específicos de la arquitectura.

P: ¿Cuánto control podría tener un desarrollador sobre el código generado para el hardware? ¿Cuánto control pueden tener sobre la gestión de la memoria entre el sistema y varios aceleradores?

Tomamos prestado el concepto de búfer de SYCL, que otorga un control de memoria muy explícito al usuario, pero además de eso, también agregamos la noción de memoria unificada . Nuestro objetivo es permitir al programador el nivel de control que necesita, no solo para administrar la memoria, sino también para generar código rápido. Algunas de las extensiones que estamos agregando sobre SYCL son cosas como subgrupos, reducciones, conductos, etc. Eso le permitirá generar un código mucho mejor para diferentes arquitecturas.

P: Un punto interesante es la distribución oneAPI para Python: Intel enumeró específicamente NumPy, SciPy, SciKit Learn. Tengo curiosidad acerca de la ganancia de rendimiento y los beneficios de productividad que podrían desbloquearse a través de oneAPI. ¿Tienes alguna métrica sobre eso?

Esa es una excelente pregunta. Estamos apoyando ese ecosistema. ¿Por qué Python querría usar un acelerador? Es para obtener rendimiento de sus bibliotecas matemáticas, bibliotecas analíticas. Lo que estamos haciendo es "conectar" NumPy, SciPy, SciKit Learn, etc., para que podamos obtener un buen rendimiento aprovechando las bibliotecas que tenemos encima. La implementación predeterminada de NumPy, SciPy, SciKit Learn, etc., en comparación con la que está conectada correctamente con paquetes nativos optimizados, puede generar ganancias muy, muy grandes. Hemos visto ganancias del orden de 200x, 300x, etc.

Nuestro objetivo con Python es que querríamos estar dentro de una fracción razonable, dentro de 2x, tal vez dentro del 80 por ciento del rendimiento del código nativo. El estado del arte actual es que con frecuencia estás en 10x o más. Realmente queremos cerrar esa brecha al realizar todas las tareas de alto rendimiento para que esté dentro de un factor de 2, y en realidad mucho más alto que eso.

P: ¿De qué tipos de hardware estamos hablando? ¿Podrían los desarrolladores desbloquear este potencial en una estación de trabajo normal o necesitaría algo un poco más potente?

No, estaría en todas partes. Si piensas de dónde viene la ganancia, lo entenderás. Las bibliotecas normales de Python no utilizan ninguna de las capacidades de virtualización en las CPU. No están usando ninguna de las capacidades multinúcleo en las CPU. No están optimizados, el sistema de memoria y todo eso no está optimizado. Por lo tanto, todo se reduce a una multiplicación de matriz escrita por un programador ingenuo y compilada por un compilador sin ninguna optimización, y luego se compara con lo que escribe un experto en código ensamblador. Puede ver ganancias multi-100x cuando compara esos dos, y en el mundo de Python, esencialmente, eso es lo que está sucediendo.

Los intérpretes de Python y las bibliotecas estándar son de tan alto nivel que el código con el que termina se convierte en un código muy, muy ingenuo. Cuando lo conecta correctamente con bibliotecas optimizadas, obtiene esas enormes ganancias. Una computadora portátil ya tiene de dos a seis u ocho núcleos de CPU, son de subprocesos múltiples y tienen capacidades de vectorización bastante decentes, tal vez 256, tal vez 512. Por lo tanto, hay mucho rendimiento en las computadoras portátiles y estaciones de trabajo. Cuando escala eso a GPU, una vez que tiene gráficos disponibles, puede imaginar de dónde provienen las ganancias.

Si observa nuestros gráficos integrados, también se están volviendo muy poderosos. Estoy seguro de que has visto el Ice Lake Gen 11, donde los gráficos integrados son significativamente mejores que los de la generación anterior. Puede ver de dónde vendrían los beneficios, incluso en las computadoras portátiles.

P: ¿Qué pasa con la disponibilidad de DevCloud? Si no recuerdo mal, es de uso gratuito para todos en este momento, pero ¿seguirá siendo así después de que alcances el oro el próximo año?

Buena pregunta. En este punto, seré honesto, no sé la respuesta. Nuestra intención en este punto es que sea gratis para siempre. Es para desarrollo, para jugar, y hay mucha potencia allí, por lo que la gente realmente puede hacer sus carreras.

P: Entonces, ¿no le importaría si le pedimos a algunos miles de desarrolladores que lo prueben?

Absolutamente no. ¡Nos encantaría que eso sucediera!

Puedo resumir lo que estamos tratando de hacer. Primero, estamos muy, muy entusiasmados con oneAPI. Es hora de que despegue una solución de múltiples proveedores, ya que ahora hay múltiples proveedores disponibles en el mercado. Si echa un vistazo a nuestra línea de procesadores, no solo a las GPU que están por venir, a GPU integradas cada vez más potentes y a nuestra hoja de ruta de FPGA, este es un momento emocionante para crear un estándar para todo eso. Nuestro objetivo es la productividad, el rendimiento y la infraestructura de la industria para que pueda desarrollarlos.

En cuanto a las tres audiencias de las que hablé, los desarrolladores de aplicaciones pueden aprovechar las cosas fácilmente, ya que ya están disponibles. Los proveedores de hardware pueden aprovechar la pila de software y conectar nuevo hardware, mientras que los proveedores de herramientas e idiomas pueden usarlo fácilmente. Intel no puede desarrollar todos los lenguajes y todas las herramientas del mundo, por lo que es una infraestructura de código abierto que otros pueden aprovechar y desarrollar muy fácilmente.