Design: Documentar por qué los bits de NaN no son completamente deterministas

Otra cosa a tener en cuenta es que los bits NaN son difíciles de observar accidentalmente

¿Hay alguna forma de hacerlos imposibles de observar o al menos el bit de señal?

En mi opinión, los no determinismos de NaN deben dejarse en paz, dado que es muy raro que el software se preocupe por ellos. ¿Cuál es el caso de sacrificar el rendimiento para hacerlos deterministas?

Aquí hay una lista de las formas en que se pueden observar los bits de NaN:

• reinterpret conversión
• store a la memoria lineal y cargue los bits con una interpretación diferente (o deje que los bits se observen externamente)
• pasar un argumento a call de una función importada, o devolver un valor de una función exportada
• copysign el signo mordió en un no-NaN

Las máquinas virtuales podrían insertar código canonicalizador antes de cada uno de estos; esa es la idea de "canonicalizar en puntos de escape" discutida anteriormente. store es muy común en rutas calientes, por lo que probablemente aún sea bastante costoso.

@qwertie Me aquí, hay formas de hacerlo completamente determisítico, incluso si no entra en la especificación.

@qwertie Los beneficios pueden incluir una portabilidad ligeramente mayor (existe código en el mundo que utiliza imprudentemente la función IEEE 754 totalOrder, por ejemplo), una reproducibilidad ligeramente mayor e invariantes más fuertes al realizar cálculos simétricos en varios nodos.

store es muy común en rutas calientes, por lo que probablemente aún sea bastante costoso.

Para este caso, ¿podríamos especificar siempre el valor del signo? ¿Así que solo hazlo 1 si se coloca en la memoria?

@wanderer Eso es esencialmente lo que implica la canonicalización: verifique si el valor es un NaN y, de ser así, aplique alguna corrección. Por lo general, es una comparación adicional y una bifurcación en la ruta activa.

También debo agregar, no he comparado ninguna de las opciones mencionadas en este número; cualquier evaluación comparativa que cualquiera pueda agregar aquí sería bienvenida.

Me inclinaría fuertemente hacia el nivel actual de no determinismo, que favorece el desempeño.
De hecho, me sorprendió un poco que wasm defina rigurosamente los bits de mantisa de NaN.
Si bien esto puede ser suficiente para los procesadores de hoy, quién sabe qué procesadores futuros vendrán.

Si el wasm se genera a partir de un lenguaje de alto nivel, ese traductor podría proporcionar una opción para controlar el nivel de semántica FP, similar a -ffast-math, por ejemplo. Luego, el traductor podría insertar cualquier corrección adicional de wasm necesaria para obligar a los nans al formato deseado. Con ese fin, podríamos proporcionar operadores isNan o normalizeNan, aunque no estoy abogando por esto ahora.

En resumen, "arreglar" esto es mejor dejarlo a una herramienta de nivel superior, en mi opinión.

+1 @mbodart. Editar : oh, mira, en realidad hay una cosa +1 ahora :). Por cierto, personalmente creo que Wasm = dominación mundial y que, por lo tanto, los futuros procesadores no se opondrán a ello.

Me gustaría cuantificar los efectos de esto en el rendimiento antes de tomar una decisión. Creo que nuestras cadenas de herramientas todavía son demasiado inmaduras para realizar buenas mediciones de rendimiento en este momento (hay polos más largos en el camino de esta). Dicho de otra manera: quiero evitar "la muerte por mil cortes".

Estoy de acuerdo con @jfbastien. Los efectos del rendimiento deben cuantificarse primero antes de jugar con la semántica.

Para ser claros, actualmente no estoy abogando por un cambio aquí; Estoy recopilando material de justificación. Un poco de no determinismo sobresale y quiere una explicación. Y hasta donde yo sé, nadie ha cuantificado los efectos en el rendimiento de hacer que estos bits no sean deterministas tampoco.

ARMv8 no siempre propaga el primer operando cuando ambos operandos son NaN. La regla es:

• Si un operando es un NaN silencioso y el otro es un NaN de señalización, propague la NaN de señalización.
• De lo contrario, propague el primer operando.

Mientras leo las especificaciones, esto se aplica a los modos Aarch32 y Aarch64 de ARMv8.

Este comportamiento es diferente del SSE que propaga el primer operando en ambos casos.

Ambas arquitecturas convertirán un sNaN en un qNaN estableciendo el bit de silencio antes de propagarlo.

@stoklund ¡ Buen lugar! Me perdí que ARM elegir el primer NaN no sucede en el caso en el que el segundo NaN está señalando. Eso complicaría la estrategia que expuse para el caso de NaN múltiple anterior, por lo que podemos mencionarlo en la justificación.

Ahora he creado el número 973 para proponer un texto específico que resuma lo anterior.