¿Cómo debo reportar la información de perfil / tiempo sobre mi código?

He visto muchas publicaciones en revistas de física computacional que utilizan diferentes métricas para el desempeño de su código. Especialmente para el código GPGPU, parece que hay una gran variedad de resultados de tiempo que la gente publica. En particular, he visto:

Comparaciones de (esencialmente) ejecutarse timeen las versiones de GPU y CPU e informar un promedio
Comparaciones de datos de perfil en cada función de GPU / CPU llamada (por lo tanto, cronometrando el funcionamiento mainy todas las funciones llamadas desde ella, pero ignorando el tiempo de inicialización del controlador)
Comparaciones de perfiles de datos para varias funciones relevantes, ignorando cosas como transferencias de memoria (a través del bus PCI-E en este caso), E / S en el disco, transformando los datos de un formato a otro, etc.
Comparaciones de datos de perfil para una sola función (por ejemplo, comparar solo el tiempo para hacer actualizaciones de giro en una CPU vs GPU Quantum Monte Carlo) e ignorar cosas como el tiempo de transferencia de memoria, E / S al disco, configurar el Hamiltoniano / diagonalizarlo etc.

Creo que la primera opción es la más 'honesta' de las cuatro, aunque también puedo ver los méritos de la segunda y la tercera. Es un poco ridículo informar una diferencia de tiempo de ejecución de 5 segundos cuando 4.99 segundos era la diferencia en las implementaciones de E / S entre idiomas o Infiniband vs Gigabit. La última opción me parece un poco "incompleta", ya que a menos que esta función sea el punto de dolor de todo el programa que informa sobre ella, no reflejará el rendimiento que vería alguien que replica mis resultados. ¿Cuál de estos enfoques es más directo? Idealmente, un documento contendría todo esto, pero en el caso de una limitación en las cifras / longitud, ¿cuál es / es más valioso, honesto y relevante para proporcionar?

performance publications documentation

— limas
fuente

Respuestas:

El tiempo de ejecución total (reloj de pared) es la única métrica que importa en la industria o en aplicaciones de la vida real: esta cifra nunca debe omitirse, incluso si es vergonzoso. Por supuesto, esta métrica depende mucho del entorno de prueba, por lo que debe describirse en detalle.

Todas las demás métricas pueden (o deberían) informarse si proporcionan información sobre el problema, o pueden extraerse conclusiones interesantes (por ejemplo, la verificación de algún límite teórico).

Creo que esta entrada de blog aborda este punto, especialmente el último párrafo.

— Stefano M
fuente

Incluso el tiempo del reloj de pared me parece posiblemente engañoso, porque la calidad de las implementaciones de cada algoritmo es importante. Joel Spolsky aborda el tema de "no existe el código más rápido" en una publicación de blog. Sin publicar el código fuente de las implementaciones (y sospecho que en algunos casos, incluso si se publica el código fuente de las implementaciones), ¿cómo voy a saber qué es realmente "más rápido"? Dicho de otra manera, ¿cómo se puede hacer una comparación de los tiempos del reloj de pared (o cualquier otra métrica) significativa?

— Geoff Oxberry

@GeoffOxberry En un pasado lejano, casi todos los cálculos eran en serie, y la jerarquía de la memoria era de solo dos niveles, dentro y fuera del núcleo. En esos días (felices) matlabtodavía se informó el flopsconteo después de cada comando ... Hoy en día tenemos CPUS multinúcleo, GPGPUS, clústeres, nubes, cachés L1 / L2 / L3, ... La eficiencia está determinada por qué tan bien puede mapear un algoritmo a la arquitectura hw / sw dada. Es una tontería tratar de condensar todo en una sola figura, pero, sin embargo, deberíamos poder introducir un pedido y decir, en algunas condiciones determinadas y bien definidas, quién es más rápido.

— Stefano M

Sí estoy de acuerdo. Me pregunto cómo se debe introducir tal orden para hacer comparaciones significativas que determinarán, en cualquier condición dada y bien definida que especifique, quién es más rápido.

— Geoff Oxberry

+1 Todo esto tiene sentido, y depende del punto que uno esté tratando de hacer en la publicación. Si el punto es sobre el rendimiento, entonces debe explicarse con mucho más cuidado.

— Mike Dunlavey

A menudo se da el caso de que solo se puede informar la punta del iceberg de todo el trabajo y los compromisos que se incluyeron en una pieza de software. El rendimiento de los informes es bueno, pero el verdadero problema es cuando el código se hace libremente accesible en Internet, de esta manera, cualquier persona interesada puede evaluar y reproducir los resultados.

Idealmente, si libera el software, también puede poner a disposición las pruebas que generan los datos presentados en un documento.

— fcruz
fuente

Estoy completamente de acuerdo: las figuras desnudas no tienen sentido. Para tener un código fuente de resultados reproducibles y significativos, los conjuntos de datos de prueba, la configuración hw y la configuración sw deben hacerse públicos.

— Stefano M

En el caso de que haya implementado un algoritmo dos veces, una en la GPU y otra en la CPU, estoy de acuerdo en que las configuraciones HW / SW son absolutamente necesarias para incluir. Todavía no tengo claro qué datos presentar en el caso de que encuentre un "efecto de escala" (por ejemplo, comparar la aceleración frente al tamaño de la matriz para la DE). ¿Debo comparar los relojes de pared? ¿Solo la parte ED del cálculo?

— limes

Si está interesado en una profunda comparación de códigos, me gusta el trabajo de Volkov y Demmel, en su papel (un poco viejo pero ilustrativo): Evaluación comparativa GPU para sintonizar densa álgebra lineal

— fcruz