Comparación de métodos de iteración: número de iteraciones vs. tiempo de CPU

Estoy comparando dos métodos iterativos para invertir matrices cuadradas aleatorias. Dado que las matrices son aleatorias, cada caso de prueba toma diferentes cantidades de iteraciones y diferentes tiempos transcurridos. Mi pregunta es, además del tiempo medio de CPU, el valor medio de las iteraciones tomadas por los dos métodos, información útil para comparar los métodos.

performance benchmarking

— srijan
fuente

Reescribí su pregunta para que sea más clara. Asegúrate de no haber cambiado tu significado de ninguna manera.

— Godric Seer

@GodricSeer Su edición ha mejorado mi pregunta. Gracias

— srijan

Respuestas:

En general, ambos métodos de comparación de desempeño tienen su lugar.

Comparar el tiempo de la CPU es, en cierto sentido, la métrica más interesante, porque al final del día estás realmente interesado en cuál de los métodos es más rápido. (Pero asegúrese de que los criterios de terminación sean comparables; por ejemplo, que ambos métodos produzcan una aproximación con la misma precisión). El inconveniente es que esto solo le dice qué método (y más importante, qué implementación ) es más rápido en la máquina en la que realizó las pruebas. No hay garantía de que una máquina diferente con una arquitectura o software diferente elegiría al mismo ganador.
La comparación de los números de iteración , por otro lado, es independiente de la máquina, pero puede ser engañosa si los dos métodos tienen iteraciones muy diferentes; en este caso, el método con menos pero más costosas iteraciones podría no ser preferible (por ejemplo, métodos de Newton vs. gradiente para la optimización si solo necesita una precisión muy baja).

Entonces, sí, tiene sentido dar ambos números [1], y lo he visto con frecuencia en publicaciones. También hay una tercera opción:

Comparación de números de operaciones elementales . Si ambas iteraciones consisten en el mismo tipo de operación adecuadamente costosa, pero requieren un número diferente (posiblemente ni siquiera el mismo número en cada iteración), tiene sentido contar el número total de estas operaciones. En su caso, un candidato probable sería el vector matriz o las multiplicaciones matriz-matriz.

[1] Definitivamente presentar estadísticas sobre múltiples ejecuciones; si muestra medios, no olvide incluir desviaciones estándar también.

— Christian Clason
fuente

¡No solo tomes los medios! Si tiene suficientes puntos de prueba con entradas aleatorias, trace una distribución.

— Bill Barth

@BillBarth: buen punto, aunque eso no siempre es factible; pero siempre debe ser posible proporcionar desviaciones estándar junto con la media. De hecho, qué estadísticas presentar para informar el rendimiento suena como una excelente pregunta de seguimiento.

— Christian Clason

@BillBarth Hiciste un buen punto. Pero, estoy usando varias matrices de prueba en orden creciente. Para tales casos, no es factible trazar la distribución, ya que tengo que trazar las distribuciones para todas las demás matrices de prueba. Por eso quería tabularlos. Gracias por tus comentarios.

— Sri Lanka

@srijan: tendrás los datos, debes trazar histogramas por ti mismo siempre que puedas. No tiene que publicarlos todos, pero le prometo que un gráfico de la distribución le dirá más que un mar de números o solo los promedios.

— Bill Barth

Incluiría el tiempo de ejecución por iteración. Como cada matriz es diferente, puede tener un número diferente de iteraciones con diferentes tiempos de ejecución. Junto con lo que dijo @Cristian, el tiempo de ejecución por iteración sería útil.

— jbcolmenares

Encuentro que el número de iteraciones es una métrica engañosa porque sugiere "velocidad" cuando no lo es. Para ver un ejemplo simple de comparación de algunos preacondicionadores diferentes que muestran esta diferencia, consulte aquí: http://www.dealii.org/developer/doxygen/deal.II/step_6.html#Possibilitiesforextensions

— Wolfgang Bangerth
fuente

Gracias por la respuesta. No puedo entender el número de iteraciones de esta línea como una métrica engañosa porque sugiere "velocidad" cuando no lo es. El ejemplo que ha sugerido es algo difícil de entender para mí.

— Sri Lanka

Lo que digo es que a menudo presentamos "número de iteraciones" para que sea equivalente al "tiempo de CPU utilizado", lo que implica que un método que requiere menos iteraciones también es más rápido. Pero eso no es cierto, como lo demuestran las cifras a las que me vinculé.

— Wolfgang Bangerth

Ahora, entendí completamente tu punto. Lo mismo he observado con el método de newtons para aproximar el inverso de una matriz cuadrada. A medida que aumenta el orden del método, el tiempo inicial de la CPU y el número de iteraciones disminuyen, pero a medida que aumenta el orden, el tiempo de inicio de la CPU aumenta aunque el número de iteraciones disminuya. Muchas gracias por su respuesta.

— Sri Lanka

En caso de que no esté claro en las otras respuestas, para qué número de iteraciones son buenos los argumentos big-O.

No es bueno para la velocidad absoluta, porque eso depende del tiempo promedio por iteración, que puede diferir entre los métodos en un factor importante.

Por ejemplo, existe una tendencia a ignorar el costo de calcular los índices de la matriz, y eso puede representar una gran fracción del tiempo de CPU.

AGREGADO: Además, como he señalado en otra parte, por cada invocación del método generalmente hay un costo de configuración. Entonces, si las matrices generalmente no son muy grandes, ese costo de configuración puede en sí mismo representar una gran fracción del tiempo de CPU (de tal manera que eliminarlo supondría una gran diferencia en la velocidad).

— Mike Dunlavey
fuente