Design: Propuesta: Indicadores de nivel de cumplimiento de Fp IEEE para Wasm (FP-Fast-Math para Wasm Scalar y SIMD)
Los compiladores nativos como gcc, clang, msvc permiten a los desarrolladores establecer niveles de cumplimiento de fp IEEE a través de pragmas o indicadores de tiempo de compilación como /fp(strict-fast), ffast-math, -ffp-contract, etc. Estos indicadores son beneficiosos para una amplia gama de aplicaciones (p. ej., convoluciones ML, DSP, motores gráficos/físicos de baja precisión...) donde los desarrolladores prefieren sacrificar la precisión portátil por el rendimiento.
Las ganancias de rendimiento pueden ser significativas según la configuración específica y los compiladores utilizados. Estas sugerencias/preferencias para desarrolladores permiten a los compiladores realizar de manera segura más optimizaciones matemáticas Fp, una mejor selección de instrucciones (fusión/fma), restricciones de rango de valores y validaciones relajadas.
Actualmente, estas marcas, cuando los desarrolladores las especifican para Wasm, son consumidas por la cadena de herramientas del desarrollador y pueden respetar algunas según la herramienta específica utilizada (p. ej., https://github.com/WebAssembly/binaryen/pull/3155). Esta información de preferencias se descartará si no están disponibles/visibles para los tiempos de ejecución si desean usarlas.
Los tiempos de ejecución de Wasm pueden beneficiarse de tener los medios para acceder a estos indicadores/sugerencias de desarrollador para tomar sus propias decisiones sobre optimización y selección de instrucciones cuando sea seguro hacerlo. Esto será particularmente útil para realizar optimizaciones de tiempo de ejecución adicionales, especialmente en compiladores AOT wasm. Esto también ayuda a abordar algunos de los problemas de rendimiento conocidos en FP Wasm SIMD codegen como redondeo, mínimo/máximo, etc. Uno de alto nivel, esto permitirá que los tiempos de ejecución no dependan de las herramientas de desarrollo para ciertas optimizaciones de FP y elimina un bloqueador para Wasm para realizar un seguimiento del rendimiento nativo más de cerca.
Existe el precedente de JVM 1.2 que relaja el cumplimiento de IEEE como modo predeterminado e introduce el modificador 'strictfp' para garantizar la portabilidad en una granularidad de clase/interfaz/método. Existe la oportunidad de explorar un enfoque más compatible con versiones anteriores para Wasm.
Me gustaría proponer un mecanismo para codificar las banderas de cumplimiento de fp IEEE en el binario Wasm para que las consuman los motores de tiempo de ejecución. Como es el caso en los lenguajes nativos, las banderas en sí pueden tratarse como opcionales y su uso puede ser una elección de los tiempos de ejecución. El impacto se manifestará como un rendimiento mejorado, una semántica coherente en una plataforma determinada y una menor portabilidad de la plataforma. El mecanismo propuesto permitirá marcar sin ambigüedades secciones de código dentro de un binario Wasm con estas preferencias/sugerencias sobre la granularidad de un bloque de instrucciones.
El diseño se puede pulir en detalle a medida que avanzamos. Una opción es introducir una nueva sección personalizada con preferencias de marcado de entradas y compensaciones de segmento de código y otra opción es introducir una nueva instrucción para marcar segmentos de código con estas preferencias de desarrollador como en JVM. Las banderas específicas para admitir se pueden discutir e incorporar a medida que avanzamos (por ejemplo, -fp-finate-math-only, -fp-no-signed-zeros ..)
Este mecanismo complementará las discusiones para agregar Scalar / Vector FMA e instrucciones de aproximación FP a las especificaciones Wasm y/o SIMD.
Este problema es para rastrear el interés en este tema y discutirlo en la sincronización de CG.
arunetm
Todos 7 comentarios
Dado que el rigor de las operaciones fp afecta la semántica de un programa, esperaría que la mejor manera de hacer posible una semántica más permisiva sea introducir nuevas instrucciones en lugar de una sección personalizada o una construcción de bloque. Ya tenemos los mecanismos de especificación necesarios para manejar el no determinismo flotante debido a nuestras reglas de propagación NaN, por lo que espero que sea sencillo introducir nuevas instrucciones de punto flotante que permitan obtener más resultados posibles.
tlively
en 12 ene. 2021
Como contexto adicional, la JVM, por su parte, está considerando eliminar strictfp y solo admitir la semántica estricta.
sunfishcode
en 12 ene. 2021
la mejor manera de hacer posible una semántica más permisiva sería introducir nuevas instrucciones en lugar de una sección personalizada o una construcción de bloque.
La introducción de nuevas instrucciones es útil, pero no escalará demasiado bien ni eliminará la dependencia de la cadena de herramientas por completo. Las instrucciones con buen soporte de plataforma como fma, recíproco, etc. son buenas candidatas para la adición de nuevas instrucciones. Existe una variedad considerable
-fassociative-math
-ffast-math
-fno-honor-nans
-ffinate-math-only
-fdenormal-fp-math
-fno-strict-float-cast-overflow
-fno-math-errno
-fno-trapping-math
...
La mayoría de estos son consejos para permitir optimizaciones fp más agresivas que eliminan las restricciones sobre transformaciones algebraicas, nans, ceros con signo, trampas, redondeo, etc. Expresar todas las banderas útiles como nuevas instrucciones no es lo ideal, en mi opinión.
Como contexto adicional, la JVM, por su parte, está considerando eliminar strictfp y solo admitir la semántica estricta.
¡Gracias @sunfishcode por este contexto agregado! No sabía acerca de esta nueva actualización y parece que la motivación es consolidar las variantes de la biblioteca matemática. En una mirada más cercana, Java strict-fp parece ser un poco más especializado y no es una buena representación del rango de puntos de control que ofrece gcc/clang. Las banderas -ffast-math y las banderas asociadas parecen ser bastante populares en los repositorios nativos a partir de una búsqueda rápida en github. Planeo investigar los usos de las banderas anteriores y los pargmas asociados
arunetm
en 12 ene. 2021
Los proyectos típicos que usan -ffast-math de gcc/clang están compilando en código nativo. Los desarrolladores de aplicaciones que los utilizan suelen probar todas las variantes de código nativo que ellos mismos crean. Y dado que todos los ISA de hardware populares tienen un comportamiento de punto flotante totalmente determinista, una vez que los desarrolladores hayan probado esas variantes, pueden estar bastante seguros de que el comportamiento no cambiará para sus usuarios. Actualmente, el punto flotante de WebAssembly también funciona de esta manera; es totalmente determinista, al igual que las ISA de hardware, por lo que se mantienen las suposiciones existentes de los desarrolladores sobre la posibilidad de agregar -ffast-math y probar que "funciona para ellos".
Un indicador -ffast-math de nivel de WebAssembly significaría que WebAssembly ya no se parece a un ISA de hardware en este sentido y ya no mantiene estas suposiciones. Los desarrolladores probarían el binario que producen, pero cuando envían wasm a sus usuarios, estos deben esperar poder ejecutarlo en diferentes hardware o diferentes motores. Con indicadores similares a las matemáticas rápidas en el nivel de WebAssembly, WebAssembly no se comportaría como un ISA, y los usuarios podrían ver resultados de punto flotante diferentes a los que probó el desarrollador.
También vale la pena señalar que los proyectos que usan estos indicadores no se pierden al compilar en WebAssembly hoy. Por ejemplo, muchas de las optimizaciones habilitadas por -fassociative-math son optimizaciones orientadas a bucles que LLVM puede realizar antes de producir WebAssembly.
sunfishcode
en 21 ene. 2021
Sí, cualquier decisión que afecte la precisión o el comportamiento del flotador debe incorporarse al módulo Wasm mediante las herramientas. Se pueden agregar nuevas instrucciones para comportamientos que no se pueden expresar con las actuales.
aardappel
en 21 ene. 2021
Tuvimos una discusión sobre este tema en la última reunión del CG con la adición de nuevas instrucciones como medios alternativos a la meta. Parece haber un interés general en resolver esto a través de la última dirección. No tengo objeciones si las expectativas de los desarrolladores sobre las ganancias de rendimiento pueden mantenerse mediante las optimizaciones de la cadena de herramientas y la introducción de variantes de instrucciones faltantes. En ese caso, no hay una buena necesidad de justificar la propagación de estas banderas al tiempo de ejecución, comprometiendo el nivel de abstracción de Wasm. Será bueno comprender las instrucciones variantes semánticas que son necesarias para alcanzar este objetivo. Tenemos algunas instrucciones nuevas identificadas en el contexto de SIMD que pueden necesitar ser ampliadas para que coincidan con las herramientas de instrucciones que necesitan para expresar banderas de matemáticas rápidas por completo. Seguirá mirando en esa dirección.
Gracias por la respuesta.
arunetm
en 22 ene. 2021
Contenido utilizado para la discusión de CG. Wasm ffast-math.pptx
arunetm
en 1 mar. 2021
Temas relacionados
artem-v-shamsutdinov
·
6Comentarios
JimmyVV
·
4Comentarios
Artur-A
·
3Comentarios
void4
·
5Comentarios
jfbastien
·
6Comentarios
Comentario más útil
Los proyectos típicos que usan -ffast-math de gcc/clang están compilando en código nativo. Los desarrolladores de aplicaciones que los utilizan suelen probar todas las variantes de código nativo que ellos mismos crean. Y dado que todos los ISA de hardware populares tienen un comportamiento de punto flotante totalmente determinista, una vez que los desarrolladores hayan probado esas variantes, pueden estar bastante seguros de que el comportamiento no cambiará para sus usuarios. Actualmente, el punto flotante de WebAssembly también funciona de esta manera; es totalmente determinista, al igual que las ISA de hardware, por lo que se mantienen las suposiciones existentes de los desarrolladores sobre la posibilidad de agregar -ffast-math y probar que "funciona para ellos".
Un indicador -ffast-math de nivel de WebAssembly significaría que WebAssembly ya no se parece a un ISA de hardware en este sentido y ya no mantiene estas suposiciones. Los desarrolladores probarían el binario que producen, pero cuando envían wasm a sus usuarios, estos deben esperar poder ejecutarlo en diferentes hardware o diferentes motores. Con indicadores similares a las matemáticas rápidas en el nivel de WebAssembly, WebAssembly no se comportaría como un ISA, y los usuarios podrían ver resultados de punto flotante diferentes a los que probó el desarrollador.
También vale la pena señalar que los proyectos que usan estos indicadores no se pierden al compilar en WebAssembly hoy. Por ejemplo, muchas de las optimizaciones habilitadas por -fassociative-math son optimizaciones orientadas a bucles que LLVM puede realizar antes de producir WebAssembly.