¿Por qué mi solucionador paralelo es más lento que mi solucionador secuencial?

14

Estaba jugando con PETSc y noté que cuando ejecuto mi programa con más de un proceso a través de MPI , ¡parece funcionar aún más lento ! ¿Cómo puedo verificar para ver qué está pasando?

Sean Farley
fuente
No publico esto como respuesta porque es realmente un "qué" en lugar de un "cómo", pero he tenido problemas similares en el pasado que fueron causados ​​por el acceso a una sección de código protegida por mutex desde múltiples hilos. A veces tiene que verificar el bloqueo de los recursos compartidos detrás de escena.
David Z

Respuestas:

13

Esto puede surgir de factores arquitectónicos :

Si el mismo ancho de banda de memoria está disponible para uno o más procesos, no verá casi ninguna aceleración ya que SpMV y las operaciones de álgebra lineal relacionadas tienen un ancho de banda de memoria limitado.

También podría ser el caso de que la sobrecarga de comunicación abrume la computación local. Por ejemplo, en métodos iterativos lineales, recomendamos tener al menos 10,000 incógnitas por proceso.

o factores numéricos :

Los preacondicionadores paralelos son a menudo más débiles que sus homólogos en serie. Por ejemplo, el bloque Jacobi se debilita a medida que se usan más bloques. Por lo tanto, debe tener en cuenta el tiempo adicional dedicado a iteraciones lineales adicionales. Las condiciones no lineales en general no funcionan de esta manera, por lo que las iteraciones de Newton a menudo son constantes.

Matt Knepley
fuente
8

Cada vez que se intenta paralelizar un programa, hay que equilibrar varios costos, pero principalmente hay

  • El costo de ejecutar cada cálculo
  • El costo de cualquier comunicación entre esos cálculos.
  • El costo de administrar esos cálculos

Si sus cálculos son vergonzosamente paralelos , el costo de las comunicaciones será muy bajo (solo entrada y salida) y el costo de administración debería ser muy bajo.

Si tiene interdependencias entre los cálculos, el costo de las comunicaciones puede aumentar significativamente. Si tiene un algoritmo complejo que tarda un tiempo diferente en completarse para cualquier cálculo dado, entonces la complejidad de la administración aumenta, a medida que intenta hacer uso eficiente de los recursos que tiene.

Al igual que con cualquier forma de optimización, la clave es realizar una evaluación comparativa. Mire cómo funciona sin MPI, cómo funciona con MPI y un proceso, luego vea cómo se escala.

Si estás jugando con CUDA, intenta darle muchos más datos. Una prueba aquí resultó en una aceleración negativa. Le dimos 1000 veces más datos y la versión GP-GPU terminó casi al mismo tiempo, mientras que la versión que se ejecuta en la CPU principal tardó 1000 veces más.

Mark Booth
fuente
3

Te recomendaría que hagas lo siguiente:

  • Haga un perfil de la ejecución de tiempo de su código, con y sin paralelización. Si tiene dudas sobre cómo hacer esto, podemos ayudarlo si describe mejor su código.

  • Ahora puede centrarse en las partes que se ejecutan más lentamente en paralelo. Debe tener en cuenta que la comunicación entre procesos puede ser lenta. Como señalaron Mark y Sean, el hecho de que un problema pueda dividirse en hilos no significa que hacerlo sea eficiente. Tienes que mirarlo más profundamente. Pero si perfila su código, puede ayudarlo a encontrar cualquier error existente. Mis dos centavos.

Si explica lo que está haciendo con más detalle, por ejemplo, con un flujo de trabajo, alguien puede darle una mejor explicación.

jbcolmenares
fuente
@ketch: tienes razón. Lo siento y gracias por notarlo. Editado el texto.
jbcolmenares