programas - manual completo de c++ pdf
Técnicas de optimización para C++ (2)
El número de instrucciones no es una buena medida en sí misma.
Menos instrucciones retiradas (porque no hay nada más que hacer) = código más rápido.
Menos instrucciones retiradas (porque tienen que esperar dependencias) = código más lento.
A veces puede ser que más instrucciones en el código también signifiquen más instrucciones retiradas, ya que pueden usar ranuras de ejecución que de lo contrario se perderían en el caso 2.
En su charla hace unos días en Facebook: slides , video , Andrei Alexandrescu habla sobre intuiciones comunes que podrían probar que estamos equivocados. Para mí, un punto muy interesante surgió en la diapositiva 7, donde afirma que el supuesto "Menos instrucciones = código más rápido" no es cierto y que más instrucciones no necesariamente significarán un código más lento.
Aquí viene mi problema: la calidad de audio de su conversación (alrededor de las 6: 20min) no es tan buena y no entiendo muy bien la explicación, pero de lo que entiendo es que está comparando las instrucciones retiradas con la optimización de un algoritmo. Un nivel de rendimiento.
Sin embargo, a mi entender, esto no se puede hacer porque estos son dos niveles estructurales independientes. Las instrucciones (especialmente las instrucciones retiradas) son una medida muy importante y, básicamente, le da una idea sobre el rendimiento para lograr un objetivo. Si dejamos de lado la latencia de una instrucción, podemos generalizar que menos instrucciones retiradas = código más rápido. Ahora, por supuesto, hay casos en los que un algoritmo que realiza cálculos complejos dentro de un bucle producirá un mejor rendimiento a pesar de que se realiza dentro del bucle, porque romperá el bucle antes (piense en el recorrido de la gráfica). Pero, ¿no sería más útil comparar los algoritmos en un nivel de complejidad en lugar de decir que este bucle tiene más instrucciones y es mejor que el otro? Desde mi punto de vista, el mejor algoritmo tendrá menos instrucciones retiradas al final.
¿Puede alguien ayudarme, por favor, a entender a dónde iba con su ejemplo, y cómo puede darse el caso de que (significativamente) más instrucciones retiradas conduzcan a un mejor desempeño?
La calidad es realmente mala, pero creo que lo lleva al hecho de que las CPU son buenas para los cálculos, pero tienen un mal rendimiento para la búsqueda de memoria (la RAM es mucho más lenta que la CPU) y las ramas (porque la CPU funciona como canalización y las ramas podría hacer que la tubería se rompa).
Aquí hay algunos casos donde más instrucciones son más rápidas:
Predicción de ramificación : incluso si necesitamos hacer más instrucciones, pero causa una mejor predicción de ramificación, la tubería de la CPU estará llena más tiempo y se "expulsarán" menos operaciones, lo que en última instancia conduce a un mejor rendimiento . Este hilo, por ejemplo, muestra cómo hacer lo mismo, pero primero la clasificación mejora el rendimiento.
CPU Cache : si su código está más optimizado para el caché y sigue el principio de localidad , es más probable que sea más rápido que un código que no lo hace, incluso si el código no cumple la mitad de la cantidad de instrucciones. Este hilo proporciona un ejemplo para una pequeña optimización de caché: el mismo número de instrucciones puede resultar en un código mucho más lento si no está optimizado para caché.
También importa qué instrucciones se hacen. A veces, algunas instrucciones pueden ser más lentas de realizar que otras, por ejemplo, la división puede ser más lenta que la suma de enteros.
Nota : Todo lo anterior depende de la máquina y cómo / si realmente cambian el rendimiento puede variar de una arquitectura a otra.