online - El ciclo de maximización del punto flotante no finaliza en D, funciona en C++

punto flotante ieee 754 ejemplos

Question

Tengo dos programas similares, uno en C ++ y otro en D.

La compilación está en Windows7 64 bits, en binarios de 64 bits.

Versión de C ++, VS 2013:

#include <iostream>
#include <string>

int main(int argc, char* argv[])
{
    float eps = 1.0f;
    float f = 0.0f;
    while (f + eps != f)
        f += 1.0f;

    std::cout << "eps = " + std::to_string(eps) + ", max_f = " + std::to_string(f) << std::endl;
    return 0;
}

Versión D, DMD v2.066.1:

import std.stdio;
import std.conv;

int main(string[] argv)
{
    float eps = 1.0f;
    float f = 0.0f;
    while (f + eps != f)
        f += 1.0f;

    writeln("eps = " ~ to!string(eps) ~ ", max_f = " ~ to!string(f));
    return 0;
}

La versión de C ++ funciona como se esperaba y encuentra que f + e == f cuando f = 16777216.

Pero la versión D cuelga para siempre. Cuando pongo breakpoint veo que en la versión D f también 16777216 (después de funcionar por un tiempo) y Watch window (uso VisualD) muestra que (f + e! = F) es ''falso'' por lo que el ciclo debe terminar pero es no es el caso durante el tiempo de ejecución.

Creo que Assembly podría dar la respuesta, pero no soy muy bueno con eso.

Soy nuevo en D, así que debería ser el caso que utilicé mal el lenguaje / compilador (compilado con DMD solo como ''dmd test.d'' sin opciones adicionales y también desde VS con VisualD con opciones predeterminadas). ¿Alguna idea de lo que podría estar mal con la versión D del programa? ¡Gracias!

Desmontaje:

C ++:

000000013F7D1410  mov         rax,rsp  
000000013F7D1413  push        rbp  
000000013F7D1414  lea         rbp,[rax-5Fh]  
000000013F7D1418  sub         rsp,0E0h  
000000013F7D141F  mov         qword ptr [rbp+17h],0FFFFFFFFFFFFFFFEh  
000000013F7D1427  mov         qword ptr [rax+8],rbx  
000000013F7D142B  movaps      xmmword ptr [rax-18h],xmm6  
000000013F7D142F  xorps       xmm1,xmm1  
    float eps = 1.0f;
    float f = 0.0f;
000000013F7D1432  movss       xmm6,dword ptr [__real@3f800000 (013F7D67E8h)]  
000000013F7D143A  nop         word ptr [rax+rax]  
        f += 1.0f;
000000013F7D1440  addss       xmm1,xmm6  
    while (f + eps != f)
000000013F7D1444  movaps      xmm0,xmm1  
000000013F7D1447  addss       xmm0,xmm6  
000000013F7D144B  ucomiss     xmm0,xmm1  
000000013F7D144E  jp          main+30h (013F7D1440h)  
000000013F7D1450  jne         main+30h (013F7D1440h)  

RE:

000000013F761002  mov         ebp,esp  
000000013F761004  sub         rsp,50h  
{
    float eps = 1.0f;
000000013F761008  xor         eax,eax  
000000013F76100A  mov         dword ptr [rbp-50h],eax  
000000013F76100D  movss       xmm0,dword ptr [rbp-50h]  
000000013F761012  movss       dword ptr [f],xmm0  
    float f = 0.0f;
    while (f + eps != f)
        f += 1.0f;
000000013F761017  movss       xmm1,dword ptr [__NULL_IMPORT_DESCRIPTOR+1138h (013F7C3040h)]  
000000013F76101F  movss       xmm2,dword ptr [f]  
000000013F761024  addss       xmm2,xmm1  
000000013F761028  movss       dword ptr [f],xmm2  
000000013F76102D  fld         dword ptr [f]  
000000013F761030  fadd        dword ptr [__NULL_IMPORT_DESCRIPTOR+1138h (013F7C3040h)]  
000000013F761036  fld         dword ptr [f]  
000000013F761039  fucomip     st,st(1)  
000000013F76103B  fstp        st(0)  
000000013F76103D  jne         D main+17h (013F761017h)  
000000013F76103F  jp          D main+17h (013F761017h)  

Resumen

Acepte la respuesta de harold de que el comportamiento del programa se debe al uso mixto de FPU y SSE.

A continuación, se incluye un resumen de lo que sucede en el fragmento de ensamblado D. De hecho, el ciclo se ejecutará para siempre.

SSE se comporta estrictamente de acuerdo con IEEE-754 cuando f alcanza 16777216.0 y agregamos 1.0 a este valor (f + = 1.0f) aún obtenemos 16777216.0 en el registro xmm2, luego lo almacenamos en la memoria.

(f + eps! = f) expresión se calcula en la FPU. Dado que los registros de FPU tienen suficiente precisión (f + eps) da como resultado 16777217.0. Si almacenamos este resultado en la memoria en la variable flotante, obtendríamos el valor esperado 16777216.0 (ya que 16777217.0 no se representa como float). Y (f + eps! = F) sería ''falso'' y el bucle terminaría. Pero no almacenamos ningún número en la memoria y realizamos una comparación en la FPU (ya que tenemos ambos operandos). Significa que comparamos un número que se calcula estrictamente de acuerdo con IEEE-754 (f) y otro que se calcula con una precisión de 80 bits (f + eps). 16777216.0! = 16777217.0 y el bucle se ejecuta para siempre.

No soy un experto en esta área, pero para mí parece que hacer punto flotante con instrucciones SSE es más sólido, como se demostró en la versión C ++ del programa.

Actualizar

Tuve una discusión sobre el foro D http://forum.dlang.org/thread/[email protected]

Resultó que el programa se comporta correctamente, de acuerdo con la especificación del lenguaje, los cálculos intermedios se pueden realizar con mayor precisión.

La implementación robusta para cualquier compilador D es:

import std.stdio;
int main()
{
    const float eps = 1.0f;
    const float step = 1.0;

    float f = 0.0f;
    float fPlusEps = f + eps;
    while (f != fPlusEps)
    {
        f += step;
        fPlusEps = f + eps;
    }
    writeln("eps = ", eps, ", max_f = ", f);
    return 0;
}

Answer 1

Código FPU y SSE mixto, eso es ... realmente extraño. No veo absolutamente ninguna razón para implementarlo de esta manera.

Pero lo han hecho, y el resultado es que f + eps != f se evalúa con una precisión extendida de 80 bits, mientras que
f += 1.0f se evalúa usando flotadores de 32 bits.

Eso significa que el ciclo nunca puede terminar, ya que f dejará de subir antes del valor que hace
f + eps != f falso (que, en precisión de 80 bits, es enorme) se alcanza.

Answer 2

Intentar romper un bucle con! = O == con valores de coma flotante es buscar problemas.

El comportamiento diferente probablemente no se deba a que el flotador duplique el compilador de conversión de punto flotante interno de 80 bits que puede adoptar al pasar valores a la FPU.

Al extender la mantisa, en particular, algunos compiladores u optimizadores pueden decidir dejar el bit menos significativo "al azar" en lugar de ponerlo a cero. Así que 1.0f , cuando se le da a la FPU puede convertirse en 1.000000000000000000000012134432 que, de acuerdo con un float , la precisión sigue siendo 1.0 , pero cuando 1.000000000000000000000012134432 y 1.000000000000000000000089544455 (las dos colas son aleatorias) son comparados por la FPU, se ven diferentes.

Debe verificar cómo el compilador de C ++ y D trata la extensión / reducción de coma flotante y, finalmente, configura los conmutadores apropiados: si los dos compiladores no son del mismo fabricante, es probable que hayan elegido diferentes opciones para sus respectivos valores predeterminados.