¿Cuál es la estructura subyacente del rendimiento del código científico?


11

Considere dos computadoras con diferentes configuraciones de hardware y software. Cuando se ejecuta exactamente el mismo código de Navier-Stokes en serie en cada plataforma, lleva tiempo xey ejecutar una iteración para la computadora 1 y 2, respectivamente. En este caso, , es la diferencia de tiempo de iteración entre la computadora 1 y la computadora 2.Δ=xy

¿Cuál podría ser el impacto en la magnitud de ? Un candidato obvio es la CPU, mi pregunta principal es si hay otros factores que podrían estar afectando a Δ en el mismo orden que la diferencia de hardware entre las CPU.ΔΔ


44
Por supuesto, su es solo una muestra. También debe investigar cómo Δ depende del tamaño y la estructura del problema. En segundo lugar me permito sugerir al perfil del código, tratando de dividir x e y en la suma de las diferentes contribuciones, y analizar el rendimiento de diferentes partes del código con respecto al HW y SW configuraciones. ΔΔxy
Stefano M

44
CACHE LINE SE PIERDE . Eso es lo primero a considerar. La memoria es el factor de cuello de botella para muchos algoritmos.
Deer Hunter

Respuestas:


13

Esta lista no está completa, pero es de esperar que su tamaño dé una pista sobre la escala de posibles factores. Supongo que está compilando el código de origen en su plataforma de elección.

Software

  • Rendimiento estándar de la biblioteca
  • Lin Alg. Rendimiento de la biblioteca (si el software se vincula a bibliotecas externas)
  • Elección del compilador
  • Optimización del compilador
  • Banderas del compilador
  • Procesos en segundo plano (puede variar significativamente si los sistemas operativos son diferentes)

Hardware

UPC

  • Velocidad de reloj
  • Arquitectura (la misma instrucción puede tomar diferentes números de ciclos en diferentes arquitecturas)
  • Tamaños de caché
  • Latencia de caché
  • Capacidad SIMD (instrucción única, datos múltiples)

Memoria

  • número de canales
  • Velocidad

HDD

  • Velocidad de lectura / escritura (en su mayoría solo es importante para escribir resultados, por lo que esto depende de la frecuencia con la que escribe la salida en un archivo para un solucionador NS, pero podría ser importante para otros programas que hacen cosas como el procesamiento de imágenes)

Todo esto ignora los pequeños trucos y características que los diferentes fabricantes incluyen para dar a sus chips una ventaja en el mercado. Sin embargo, el problema principal es que muchas bibliotecas de álgebra lineal dispersas están vinculadas a la memoria. Hacer una multiplicación de matriz dispersa implica una gran cantidad de datos que se mueven sin muchos flops reales.


Yo agregaría, a la CPU, tanto el número de núcleos como sus capacidades SIMD.
Pedro

@Pedro Dejé los núcleos apagados ya que la pregunta decía solucionador en serie, pero agregaré SIMD. Gracias.
Godric Seer

1
@GodricSeer Compilé en una máquina y luego la ejecuté. Luego, usando el mismo ejecutable compilado, lo ejecuté en la segunda máquina. Según su explicación, parece que sería mejor volver a compilar desde la fuente en la segunda computadora. ¿Es ese el caso?
Oscilación isopícnica

1
@IsopycnalOscillation Al compilar en / para una máquina específica, puede usar la opción gcc / gfortran -march=native, o la opción icc / ifort -xHOSTque aplicará optimizaciones específicas a la arquitectura subyacente.
Pedro

1
Un punto clave aquí es que el rendimiento de la computadora no es una cantidad unidimensional. El equilibrio relativo de todos los factores que Godric ha enumerado anteriormente puede variar enormemente, incluso para computadoras con chips de procesador del mismo fabricante (por ejemplo, Intel). Como resultado, diferentes puntos de referencia pueden mostrar relaciones de rendimiento muy diferentes para dos procesadores. Como cuestión práctica, la mayoría de las máquinas modernas carecen seriamente de ancho de banda de memoria para soportar cargas de trabajo informáticas científicas y esto es a menudo el cuello de botella.
Brian Borchers

2

x/yxy

En segundo lugar, su pregunta excluye específicamente las diferencias en el software. En mi experiencia, las recompensas de rendimiento por un ajuste cuidadoso pueden ser factores importantes, por lo tanto, si está considerando problemas de hardware, no olvide los problemas de software. Después de todo, el hardware solo puede ejecutar las instrucciones que le das, y si le das menos, terminará antes.

No para expandir esto demasiado, pero para cualquier problema dado hay una infinidad contable de programas que lo resolverán. Entre estos, algunos toman menos tiempo que todos los demás, y ese es un límite inferior. No asuma que ningún programa está en este límite inferior o incluso cerca de este si no se ha ajustado cuidadosamente.

Este enlace explica en detalle el método poco ortodoxo que uso.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.