¿Valdrá la pena aritmética de punto fijo mi problema?

Question

Estoy trabajando en un solucionador de dinámica de fluidos Navier-Stokes que debe ejecutarse en tiempo real. Por lo tanto, el rendimiento es importante.

En este momento, estoy buscando un número de bucles estrechos que cada cuenta por una fracción significativa del tiempo de ejecución: no hay un solo cuello de botella. La mayoría de estos bucles realizan aritmética en coma flotante, pero hay muchas ramificaciones intermedias.

Las operaciones de coma flotante se limitan principalmente a adiciones, restas, multiplicaciones, divisiones y comparaciones. Todo esto se hace usando flotadores de 32 bits. Mi plataforma objetivo es x86 con al menos instrucciones SSE1. (He verificado en la salida del ensamblador que el compilador genera instrucciones SSE.)

La mayoría de los valores de punto flotante con los que estoy trabajando tienen un límite superior razonablemente pequeño, y la precisión para valores cercanos a cero no es muy importante. Entonces, se me ocurrió lo siguiente: ¿tal vez cambiar a la aritmética de punto fijo podría acelerar las cosas? Sé que la única manera de estar realmente seguro es de medirlo, eso puede llevar días, así que me gustaría saber las probabilidades de éxito de antemano.

El punto fijo estaba de moda en los días de Doom, pero no estoy seguro de lo que es el año 2010. Teniendo en cuenta la cantidad de silicio que se bombea actualmente en el rendimiento de punto flotante, ¿existe la posibilidad de que la aritmética de puntos todavía me dará un impulso de velocidad significativo? ¿Alguien tiene alguna experiencia en el mundo real que se pueda aplicar a mi situación?

Answer 1

Como otras personas han dicho, si usted ya está usando en coma flotante SIMD, dudo que obtendrá una gran mejora con punto fijo.

Usted dijo que el compilador emite instrucciones SSE, pero no parece que haya intentado escribir su código SSE vectorizado. No sé qué tan buenos son los compiladores en eso, pero es algo para investigar.otros

Dos áreas a consultar son:

1. acceso a la memoria - si todos los cálculos se realizan en SSE, a continuación, los errores de caché puede ser que tome más tiempo que los cálculos reales.

   1. Puede captar previamente los datos con p. Ej. _mm_prefetch o __builtin_prefetch (dependiendo de tu compilador/plataforma).
   2. Verifique sus costosas funciones para aliasing entre entradas y salidas; estos pueden llevar a lecturas/escrituras adicionales de memoria.
   3. Considere almacenar sus datos de manera diferente: si su solucionador de fluidos resuelve las coordenadas x independientemente de y, podría ser más fácil guardarlas en diferentes matrices. Si están resueltos para juntas, considere la intercalación (por ejemplo, x y x y ...)

2. Desenrollar - usted debe ser capaz de obtener un beneficio en el rendimiento de desenrollar sus lazos internos. El objetivo no es (como muchas personas piensan) reducir el número de verificaciones de terminación de bucle. El principal beneficio es permitir que las instrucciones independientes se intercalen, para ocultar la latencia de la instrucción. Hay una presentación here titulada VMX Optimization: llevándola a un nivel que podría ayudar un poco; está enfocado en las instrucciones de Altivec en Xbox360, pero algunos de los consejos de desenrollado también podrían ayudar en SSE.

Como otras personas han mencionado, perfil, perfil, perfil. Y luego háganos saber lo que todavía es lento :)

PD - en una de sus otras publicaciones here, lo convencí de usar SOR en lugar de Gauss-Seidel en su solucionador de matrices. Ahora que lo pienso, ¿hay alguna razón por la que no estés usando un solucionador de tres diagonales?

Answer 2

Stick con punto flotante. El punto fijo realmente solo es útil si puede trabajar dentro de 8 bits o 16 bits y usa SIMD (el procesamiento de imagen y el audio son casos de uso típicos para esto).

Las CPU modernas suelen tener 2 FPU y puede emitir hasta 2 instrucciones FP por ciclo de reloj. También tiene la posibilidad de optimizar utilizando 4 vías FP SIMD (SSE).

Si aún tiene problemas para obtener un buen rendimiento, intente utilizar un mejor compilador, como el ICC de Intel. Además, los ejecutables Intel de 64 bits tienden a ser algo más rápidos que sus contrapartes de 32 bits debido al aumento del número de registros en el modelo de 64 bits, por lo que compila para 64 bits si puedes.

Y, por supuesto, también debe crear un perfil de su código, para que sepa con certeza dónde están los puntos de acceso. No dice qué sistema operativo está usando, pero VTune en Windows, Zoom en Linux o Shark en Mac OS X lo ayudarán a encontrar rápida y fácilmente sus cuellos de botella de rendimiento.

Answer 3

Su máquina está muy bien optimizada para coma flotante, por lo que probablemente no ahorrará mucho yendo a fracciones de punto fijo.

Dice que no hay un único cuello de botella, pero puede haber varios, y si logra afeitar a alguno de ellos, los demás tomarán porcentajes más grandes del tiempo restante, llamando su atención sobre ellos, para que pueda afeitarse ellos tambien.

Es probable que haya hecho esto, pero me aseguraría de que no sólo las funciones que requieren mucho tiempo son lo más rápido posible, pero que están siendo llamados no más de lo necesario.