scieee AI-readable full text Open interactive document viewer

Medida del rendimiento: Benchmarks: v.1.0

Cámara Nebreda, José María

Full text

Medida del rendimiento Benchmarks V 1.0 José M. Cámara ([email protected]) Motivación El rendimiento debe ser evaluado para: Valorar el comportamiento del sistema. Comparar varios sistemas. Optimizar la utilización. Eliminar cuellos de botella. Cuantificar el rendimiento es una tarea abrumadora: Los sistemas son distintos entre sí. Son muy complejos. Manejan una amplia variedad de aplicaciones y datos. Métricas Latencia: tiempo para completar una acción: enviar un mensaje, ejecutar un programa, responder a una petición… En función de la situación se puede expresar también como tiempo de ejecución o como tiempo de respuesta. Throughput: tareas completadas por unidad de tiempo: instrucciones, mensajes, consultas… Throughput = 1/ latencia solo cuando no se produce solapamiento (pipe-line de instrucciones o de mensajes). Si no throughput > 1/ latencia. Benchmarks Concepto: programa de aplicación empleado para cuantificar el rendimiento de un computador. Objetivo: los resultados deben ser numéricos, objetivos y equitativos. Tipos:  Programas reales. Sintéticos. Kernels. Juguetes. Suites. Benchmarks Los programas reales parecen a priori la opción más objetiva, pero a menudo sus resultados son difíciles de interpretar y poco extrapolables ya que muchos sistemas se ven afectados por ellos de forma incierta y variable. Los benchmarks sintéticos se diseñan para reflejar el rendimiento de ciertos subsistemas. Para evaluar todos los subsistemas lo adecuado es emplear una suite de programas sintéticos. Los kernels son similares a programas reales. Eliminan lo que no es relevante, como la interfaz de usuario, los resultados del cálculo, etc. Los juguetes son programas cortos que producen resultados ya conocidos por el usuario. Evaluación de resultados Las suites de benchmarks están compuestas por programas diferentes. El rendimiento de los sistemas puede ser diferente bajo cada uno de ellos. Una comparación directa no es posible en este caso. Se utilizan métricas más elaboradas: Media aritmética: 𝐴𝐴𝐴𝐴 = ∑ 𝑟𝑟𝑖𝑖 𝑁𝑁 𝑖𝑖 𝑁𝑁. No es acertada cuando las pruebas no están relacionadas. La más larga tiende a marcar la tendencia. Media geométrica: 𝐺𝐺𝐴𝐴 = ∏ 𝑟𝑟𝑖𝑖 𝑁𝑁 𝑖𝑖 𝑁𝑁 . Su utilidad no está muy clara. Media armónica: 𝐻𝐻𝐴𝐴 =𝑁𝑁 ∑ 1 𝑟𝑟𝑖𝑖 𝑁𝑁 𝑖𝑖 Los resultados 𝑟𝑟𝑖𝑖 pueden ser tiempos de ejecución absolutos (o sus inversos) o incrementos (referidos a un sistema concreto). Comparación de medias Pensemos en un conjunto de pruebas en las que los tiempos de ejecución son: 1s, 4s y 10s. La media aritmética es 5s. Es correcto pero, teniendo en cuenta que los programas cortos se pueden ejecutar un número mayor de veces que los largos, quizá deberían pesar más en la media. La media armónica es 3/1,35 = 2,22s. Esto podría reflejar mejor el rendimiento global del sistema. Selección de benchmarks Sistemas distintos requieren benchmarks diferentes. Vamos a considerar dos tipos de servidores: supercomputadores y centros de datos. En los supercomputadores, independientemente del subsistema que queramos evaluar, lo que importa es el tiempo de ejecución (el throughput suele ser también relevante). Los resultados se proporcionan habitualmente como FLOPS. En los centros de datos el tiempo de respuesta es lo que el usuario percibe como “rendimiento”. El throughput no tiene mucho sentido en este ámbito. Los resultados se pueden proporcionar como relación SLO/SLA (service level objectives/agreements). Por ejemplo: 99% de respuestas en menos de 100ms. Evaluación de supercomputadores De largo, el benchmark más popular para supercomputadores es el Linpack. Proporciona el rendimiento en FLOPS bajo la ejecución de un kernel basado en la resolución de sistemas de ecuaciones lineales. Es el banco de pruebas para el ranking Top500. NAS NPB: es una suite de kernels desarrollada por la NASA. Los kernels intentan reflejar el núcleo de cálculo de aplicaciones típicas en mecánica de fluidos junto con otras aplicaciones habituales relacionadas con su actividad. Todos los benchmarks llevan asociados cálculos pesados; difieren en el problema que resuelven y en el volumen de tráfico de comunicación que generan: EP: Embarrassingly Parallel. Conlleva cálculo pero poca comunicación entre procesos. MG: Multigrid. A diferencia del anterior provoca comunicación entre procesadores próximos y lejanos. CG: Conjugate Gradient. Provoca un bajo volumen de comunicación muy esparcida entre nodos próximos y lejanos. FT: Fourier Transform. Patrón de comunicación abundante y uniformemente distribuida. IS: Integer Sort. La comunicación es pesada y uniforme, pero no tan pesada ni uniforme como en el caso anterior. LU, SP & BT: abordan el mismo problema matemático usando algoritmos diferentes. BT es “menos paralela” que el resto.