He encontrado que el reloj habitual (), todos lo recomiendan aquí, por alguna razón se desvía enormemente de una ejecución a otra, incluso para el código estático sin efectos secundarios, como dibujar en la pantalla o leer archivos. Podría ser porque la CPU cambia los modos de consumo de energía, el sistema operativo le da diferentes prioridades, etc.
Por lo tanto, la única forma de obtener el mismo resultado de manera confiable cada vez con clock () es ejecutar el código medido en un bucle varias veces (durante varios minutos), tomando precauciones para evitar que el compilador lo optimice: los compiladores modernos pueden calcular previamente el código sin los efectos secundarios que se ejecutan en un bucle, y moverlo fuera del bucle., por ejemplo, usando una entrada aleatoria para cada iteración.
Después de recolectar suficientes muestras en una matriz, se ordena esa matriz y se toma el elemento central, llamado mediana. La mediana es mejor que la media, ya que arroja desviaciones extremas, como decir que el antivirus ocupa toda la CPU o el sistema operativo haciendo alguna actualización.
Aquí hay una sencilla utilidad para medir el rendimiento de ejecución del código C / C ++, promediando los valores cercanos a la mediana: https://github.com/saniv/gauge
Todavía estoy buscando una forma más robusta y rápida de medir el código. Probablemente se podría intentar ejecutar el código en condiciones controladas en el metal desnudo sin ningún sistema operativo, pero eso dará un resultado poco realista, porque en realidad el sistema operativo se involucra.
x86 tiene estos contadores de rendimiento de hardware, que incluyen el número real de instrucciones ejecutadas, pero son difíciles de acceder sin ayuda del sistema operativo, difíciles de interpretar y tienen sus propios problemas ( http://archive.gamedev.net/archive/reference/articles /article213.html ). Aún así, podrían ser útiles para investigar la naturaleza del cuello de la botella (acceso a datos o cálculos reales sobre esos datos).