¿Cuándo debo usar la palabra clave" strictfp " en java?

Wikipedia en realidad tiene un buen artículo sobre este tema aquí , con un enlace a la especificación Java.

Leyendo entre líneas, la implicación es que si no especifica strictfp, entonces el compilador JVM y JIT tienen licencia para calcular sus cálculos de coma flotante como quieran. En aras de la velocidad, lo más probable es que deleguen el cálculo a su procesador. Con strictfp en, los cálculos tienen que ajustarse a los estándares aritméticos IEEE 754, que, en práctica, probablemente significa que la JVM hará el cálculo.

Entonces, ¿por qué querrías usar strictfp? Un escenario que puedo ver es en una aplicación distribuida (o juego multijugador) donde todos los cálculos de coma flotante deben ser deterministas sin importar el hardware o la CPU subyacentes. ¿Cuál es la compensación? Lo más probable es el tiempo de ejecución.

Aquí hay varias referencias:

• Usando strictfp (Consejo técnico de JDC)

• JGuru: ¿Para qué sirve el modificador strictfp? ¿Cuándo consideraría usarlo?

  Básicamente, todo se reduce a si le importa o no que los resultados de las expresiones de coma flotante en su código sean rápidos o predecibles. Por ejemplo, si necesita las respuestas que su código obtiene que utilizan valores de coma flotante para ser consistentes en múltiples las plataformas usan strictfp.

• Strictfp-Java Glossary

  El hardware de coma flotante calcula con más precisión, y con un rango de valores mayor que el que requiere la especificación Java. Sería confuso que algunas plataformas dieran más precisión que otras. Cuando se utiliza el modificador strictfp en un método o clase, el compilador genera código que se adhiere estrictamente a la especificación de Java para obtener resultados idénticos en todas las plataformas. Sin strictfp, es es ligeramente más laxo, pero no tan laxo como para usar los bits de guardia en el Pentium para dar 80 bits de precisión.

• Y finalmente la Especificación actual del Lenguaje Java, §15.4 FP-strict Expressions :

  Dentro de una expresión FP-strict, todos los valores intermedios deben ser elementos del conjunto de valores float o del conjunto de valores double, lo que implica que los resultados de todas las expresiones FP-strict deben ser los predichos por la aritmética IEEE 754 en operandos representados uso de formatos simples y dobles. Dentro de una expresión que no es FP-strict, se concede cierto margen para que una implementación use un rango de exponentes extendido para representar resultados intermedios; el efecto neto, en términos generales, es que un cálculo podría producir "la respuesta correcta" en situaciones donde el uso exclusivo del conjunto de valores flotantes o el conjunto de valores dobles podría resultar en desbordamiento o desbordamiento.

Nunca he tenido personalmente un uso para él, sin embargo.

Todo comenzó con una historia,

Cuando Java estaba siendo desarrollado por James Gosling, Herbert y el resto de su equipo. Tenían esta locura en mente llamada independencia de la plataforma. Querían hacer oak(Java) mucho mejor que se ejecutara exactamente igual en cualquier máquina con un conjunto de instrucciones diferente, incluso ejecutando diferentes sistemas operativos. Pero, hubo un problema con los números de punto decimal también conocidos como punto flotante y doble en la programación idioma. Algunas máquinas se construyeron apuntando a la eficiencia, mientras que el resto apuntaba a la precisión. Por lo tanto, las máquinas posteriores(más precisas) tenían un tamaño de punto flotante de 80 bits, mientras que las primeras(más eficientes/rápidas) tenían dobles de 64 bits. Pero, esto estaba en contra de la idea central de construir un lenguaje independiente de la plataforma. Además, esto podría conducir a la pérdida de precisión/datos cuando un código se construye en alguna máquina (con doble de 64 bits de tamaño) y se ejecuta en otro tipo de máquina (con doble de 80 bits Tamaño).

El tamaño ascendente puede ser tolerado, pero el tamaño descendente no puede ser. Por lo tanto, se encontraron con un concepto de strictfp, es decir, punto flotante estricto. Si utiliza esta palabra clave con una clase / función entonces su coma flotante y dobles tienen un tamaño consistente sobre cualquier máquina. es decir, 32/64 bits respectivamente.

Como se mencionó en las otras respuestas, hace que los resultados de punto flotante intermedio se ajusten a la especificación IEEE. En particular, los procesadores x86 pueden almacenar resultados intermedios con una precisión diferente de la especificación IEEE. La situación se complica cuando el JIT optimiza un cálculo en particular; el orden de las instrucciones podría ser diferente cada vez, lo que resulta en un redondeo ligeramente diferente.

La sobrecarga incurrida por strictfp probablemente sea muy procesador y JIT dependiente. Este artículo de wikipedia sobre SSE2 parece tener alguna idea del problema. Por lo tanto, si el JIT puede generar instrucciones SSE para realizar un cálculo, parece que strictfp no tendrá ninguna sobrecarga.

En mi proyecto actual hay algunos lugares donde uso strictfp. Hay un punto en el que los rayos cósmicos potenciales deben eliminarse de los valores de píxeles. Si algún investigador externo tiene el mismo valor de píxel y rayo cósmico delante de ellos, debería obtener el mismo valor resultante como nuestro software.

• Strictfp es un modificador que restringe los cálculos de coma flotante según IEEE 754.

• Esto se puede usar en toda la clase como " public strictfp class StrictFpModifierExample {} "o en el método"public strictfp void example ()".Si se usa en la clase, todos los métodos seguirán IEEE 754 y si se usa en el método, entonces el método particular seguirá IEEE 754.

• ¿por Qué se utiliza??::: Como diferentes plataformas tienen diferentes hardware de punto flotante que calcula con más precisión y mayor rango de valores de lo que requiere la especificación java, lo que puede producir una salida diffrent en diffrent plateforms.so confirma la misma salida independientemente de las diferentes plataformas

• Strictfp también se asegura de aprovechar la velocidad y la precisión de las operaciones de punto flotante de precisión extendida.

• No hay desventaja con esta palabra clave que podemos usar cuando estamos haciendo coma flotante cálculos

• Mi último punto es What ¿Qué es IEEE754 en resumen IEEE 754 define el método estándar tanto para los cálculos de coma flotante como para el almacenamiento de valores de coma flotante en single (32 bits, utilizado en Java floats) o double (64 bits, utilizado en Java doubles) precision.It también define normas para cálculos intermedios y para formatos de precisión extendida.

strictfp es una palabra clave y se puede usar como un modificador de no acceso para clases o métodos a (pero nunca variables). Marcar una clase como strictfp significa que cualquier código de método en la clase se ajustará a las reglas estándar IEEE 754 para puntos flotantes.

Sin ese modificador, los puntos flotantes utilizados en los métodos podrían comportarse de una manera dependiente de la plataforma. Con él puede predecir cómo se comportarán sus puntos flotantes independientemente de la plataforma subyacente en la que se esté ejecutando la JVM. Desventaja es que si la plataforma subyacente es capaz de soportar una mayor precisión, un método strictfp no podrá aprovecharlo.

Si no declara una clase como strictfp, todavía puede obtener strictfp comportamiento método por método, declarando un método como strictfp.

~ SCJP Sun®Certified Programmer for Java™ 6-Kathy Sierra & Bert Bates ~

Puede que el siguiente ejemplo ayude a entender esto más claramente : En java cada vez que estamos utilizando buscando información precisa para cualquier operación, por ejemplo, si hacemos doble num1 = 10e + 102; doble num2 = 8e + 10 ; resultado = num1+ num2;

        The output will be so long and not precise, becasue it is precissed by the hardware e.g JVM and JIT has the license 
        as long as we dont have specify it Strictfp

Marking it Strictfp will make the result Uniform on every hardware and platform, because its precised value will be same
One scenario I can see is in a distributed application (or multiplayer game) where all floating-point calculations need to 
be deterministic no matter what the underlying hardware or CPU is.