Solución:
Es una medida de rendimiento bastante decente, siempre que comprenda exactamente lo que mide.
FLOPS es, como su nombre lo indica, operaciones de punto flotante por segundo, exactamente lo que constituye un FLOP puede variar según la CPU. (Algunas CPU pueden realizar sumas y multiplicaciones como una sola operación, otras no, por ejemplo). Eso significa que, como medida de rendimiento, está bastante cerca del hardware, lo que significa que 1) debe conocer su hardware para calcular los FLOPS ideales en la arquitectura dada, y debe conocer su algoritmo e implementación para descubrir cómo muchas operaciones de punto flotante en las que en realidad se compone.
En cualquier caso, es una herramienta útil para examinar qué tan bien utiliza la CPU. Si conoce el rendimiento máximo teórico de la CPU en FLOPS, puede calcular la eficiencia con la que utiliza las unidades de punto flotante de la CPU, que a menudo son una de las más difíciles de utilizar de manera eficiente. Un programa que ejecuta el 30% de los FLOPS de los que es capaz la CPU, tiene espacio para la optimización. Uno que se ejecuta al 70% probablemente no será mucho más eficiente a menos que cambie el algoritmo básico. Para algoritmos con muchas matemáticas como el suyo, esa es prácticamente la forma estándar de medir el rendimiento. Simplemente podría medir cuánto tiempo tarda en ejecutarse un programa, pero eso varía enormemente dependiendo de la CPU. Pero si su programa tiene una utilización de CPU del 50% (en relación con el recuento máximo de FLOPS), ese es un valor algo más constante (aún variará entre arquitecturas de CPU radicalmente diferentes, pero es mucho más consistente que el tiempo de ejecución).
Pero saber que “Mi CPU es capaz de X GFLOPS, y en realidad solo estoy logrando un rendimiento de, digamos, el 20% de eso” es muy información valiosa en software de alto rendimiento. Significa que algo otro que las operaciones de punto flotante lo están frenando y evitando que las unidades FP funcionen de manera eficiente. Y dado que las unidades FP constituyen la mayor parte del trabajo, eso significa que su software tiene un problema.
Es fácil medir “Mi programa se ejecuta en X minutos”, y si cree que es inaceptable, puede decir “Me pregunto si puedo reducir el 30% de eso”, pero no lo hace. saber si eso es posible a menos que averigüe exactamente cuánto trabajo se está haciendo y exactamente de qué es capaz la CPU en el pico. ¿Cuánto tiempo desea dedicar a optimizar esto, si ni siquiera sabe si la CPU es fundamentalmente capaz de ejecutar más instrucciones por segundo?
Es muy fácil evitar que la unidad FP de la CPU se utilice de manera eficiente, al tener demasiadas dependencias entre las operaciones FP, o al tener demasiadas ramas o similares que impiden una programación eficiente. Y si eso es lo que está frenando su implementación, necesitar para saberlo. Debe saber que “no obtengo el rendimiento FP que debería ser posible, por lo que claramente otras partes de mi código están impidiendo que las instrucciones FP estén disponibles cuando la CPU está lista para emitir una”.
¿Por qué necesita otras formas de medir el desempeño? ¿Qué hay de malo en calcular el recuento de FLOPS como te pidió tu jefe? 😉
Solo me gustaría agregar un par de puntos más finos:
-
división es especial. Dado que la mayoría de los procesadores pueden hacer una suma, una comparación o una multiplicación en un solo ciclo, todos se cuentan como un flop. Pero la división siempre lleva más tiempo. Cuánto tiempo más depende del procesador, pero hay una especie de estándar de facto en la comunidad HPC para contar una división como 4 flops.
-
Si un procesador tiene fusionar multiplicar-añadir instrucción que hace una multiplicación y una suma en una sola instrucción, generalmente A + = B * C, que cuenta como 2 operaciones.
-
Tenga siempre cuidado al distinguir entre precisión simple fracasos y fracasos de doble precisión. Un procesador que es capaz de tantos gigaflops de precisión simple puede que solo sea capaz de una pequeña fracción de esa cantidad de gigaflops de precisión doble. Los procesadores AMD Athlon y Phenom generalmente pueden hacer la mitad de los fracasos de precisión doble que de precisión simple. Los procesadores ATI Firestream generalmente pueden hacer 1/5 de la cantidad de flops de precisión doble que de precisión simple. Si alguien está tratando de venderle un procesador o un paquete de software y simplemente cotiza fracasos sin decir cuál, debe llamarlo.
-
Los términos megaflop, gigaflop, teraflop, etc. son de uso común. Estos se refieren a factores de 1000, no 1024. Por ejemplo, 1 megaflop = 1,000,000 flop / seg no 1,048,576. Al igual que con los tamaños de las unidades de disco, existe cierta confusión al respecto.
Pregunta antigua con respuestas antiguas, aunque populares, que no son exactamente buenas, en mi opinión.
Un “FLOP” es una operación matemática de punto flotante. “FLOPS” puede significar cualquiera de dos cosas:
- El plural simple de “FLOP” (es decir, “operación X toma 50 FLOP ”)
- los índice de FLOP en el primer sentido (es decir, operaciones matemáticas de punto flotante por segundo)
Cuando no está claro por el contexto, a cuál de estos se refiere a menudo se elimina la ambigüedad escribiendo el primero como “FLOP” y el segundo como “FLOP / s”.
Los FLOP se denominan para distinguirlos de otros tipos de operaciones de CPU., como operaciones matemáticas enteras, operaciones lógicas, operaciones bit a bit, operaciones de memoria y operaciones de bifurcación, que tienen diferentes costos (lea “toman diferentes períodos de tiempo”) asociados con ellos.
La práctica del “conteo de FLOP” se remonta a los primeros días de la computación científica, cuando los FLOP eran, en términos relativos, extremadamente costosos y tomaban muchos ciclos de CPU cada uno. Un coprocesador matemático 80387, por ejemplo, tomó algo así como 300 ciclos para una sola multiplicación. Esto fue en un momento antes de la canalización y antes de que se abriera realmente la brecha entre las velocidades de reloj de la CPU y las velocidades de la memoria: las operaciones de memoria tomaban solo uno o dos ciclos, y la ramificación (“toma de decisiones”) era igualmente barata. En aquel entonces, si podía eliminar un solo FLOP a favor de una docena de accesos a la memoria, obtenía una ganancia. Si pudieras eliminar un solo FLOP a favor de una docena de ramas, obtendrías una ganancia. Entonces, en el pasado, tenía sentido contar los FLOP y no preocuparse mucho por las referencias de memoria y las ramas porque los FLOP dominaban fuertemente el tiempo de ejecución porque individualmente eran muy costosos en comparación con otros tipos de operación.
Más recientemente, la situación se ha revertido. Los FLOP se han vuelto muy baratos: cualquier Intel moderno centro puede realizar aproximadamente dos FLOP por ciclo (aunque la división sigue siendo relativamente cara) y los accesos a la memoria y las ramificaciones son comparativamente mucho más caros: un acceso a la caché L1 cuesta quizás 3 o 4 ciclos, una recuperación de la memoria principal cuesta entre 150 y 200. Dada esta inversión, ya no es el caso de que la eliminación de un FLOP a favor de un acceso a la memoria resulte en una ganancia; de hecho, eso es poco probable. De manera similar, a menudo es más barato “simplemente hacer” un FLOP, incluso si es redundante, en lugar de decidir si hacerlo o no. Esto es todo lo contrario a la situación de hace 25 años.
Desafortunadamente, la práctica del conteo ciego de FLOP como una métrica absoluta de mérito algorítmico ha persistido mucho más allá de su fecha de caducidad. La informática científica moderna tiene mucho más que ver con la gestión del ancho de banda de la memoria. – tratando de mantener las unidades de ejecución que hacer los FLOP se alimentan constantemente de datos, de lo que se trata de reducir el número de FLOP. La referencia a LINPACK (que fue esencialmente obsoleto por LAPACK Hace 20 años) me lleva a sospechar que su empleador probablemente sea de una escuela muy antigua que no ha internalizado el hecho de que establecer expectativas de desempeño ya no es solo una cuestión de contar FLOP. Un solucionador que hace el doble de FLOP aún podría ser veinte veces más rápido que otro si tiene un patrón de acceso a la memoria y un diseño de datos mucho más favorables.
El resultado de todo esto es que La evaluación del rendimiento del software computacionalmente intensivo se ha vuelto mucho más compleja de lo que solía ser.. El hecho de que los FLOP se hayan vuelto baratos es enormemente complicado por la enorme variabilidad en los costos de operaciones de memoria y sucursales. Cuando se trata de evaluar algoritmos, el simple recuento de FLOP simplemente ya no informa las expectativas generales de rendimiento.
Quizás una mejor manera de pensar en las expectativas de desempeño y la evaluación es la que proporciona el llamado modelo de línea de techo, que está lejos de ser perfecto, pero tiene la ventaja de hacer que usted Piense en el compromiso entre el punto flotante y los problemas de ancho de banda de la memoria al mismo tiempo., proporcionando una “imagen 2D” más informativa y perspicaz que permite la comparación de las medidas de rendimiento y las expectativas de rendimiento.
Vale la pena echarle un vistazo.
Puntuaciones y reseñas
Eres capaz de añadir valor a nuestra información colaborando tu experiencia en las observaciones.