MATLAB parfor es más lento que para - ¿qué pasa?

Question

el código que estoy tratando con bucles tiene el siguiente aspecto:

bistar = zeros(numdims,numcases); 
parfor hh=1:nt  
    bistar = bistar + A(:,:,hh)*data(:,:,hh+1)' ; 
end 

para pequeñas nt (10).

Después de sincronizarlo, en realidad es 100 veces más lento que utilizando el lazo normal. Sé que parfor puede hacer sumas paralelas, así que no estoy seguro de por qué esto no está funcionando.

corro

matlabpool 

con las configuraciones de salida de la caja antes de ejecutar el código.

Soy relativamente nuevo en matlab, y recién comencé a usar las funciones paralelas, así que no asuma que no estoy haciendo algo estúpido.

Gracias!

PD: Estoy ejecutando el código en un núcleo cuádruple, así que esperaría ver algunas mejoras.

Answer 1

Hacer la partición y la agrupación de los resultados (gastos generales al dividir el trabajo y recopilar resultados de varios hilos/núcleos) es alto para valores pequeños de nt. Esto es normal, no haría particiones de datos para tareas fáciles que se pueden realizar rápidamente en un bucle simple.

Siempre realice algo desafiante dentro del ciclo que valga la sobrecarga de la partición. Aquí hay un buen introduction to parallel programming.

Los subprocesos provienen de un grupo de subprocesos por lo que la sobrecarga de la creación de los subprocesos no debería estar allí. Pero para crear los resultados parciales se deben crear las matrices n del tamaño bistar, todos los resultados parciales calculados y luego todos estos resultados parciales deben agregarse (recombinarse). En un ciclo recto, esto es con una alta probabilidad de realizarse en el lugar, no se realizan asignaciones.

La declaración completa de la ayuda (gracias por su enlace a continuación) es:

Si el tiempo para calcular f, g, h es gran, parfor será significativamente más rápido que el correspondiente a la declaración , incluso si n es relativamente pequeña.

Así que, como verá, significan exactamente lo mismo que lo que quiero decir, la sobrecarga para pequeños valores n solo vale la pena si lo que hace en el ciclo es lo suficientemente complejo/lento.

Answer 2

Parfor viene con un poco de overhead. Por lo tanto, si nt es realmente pequeño, y si el cálculo en el ciclo se realiza muy rápidamente (como una adición), la solución parfor es más lenta. Además, si ejecuta parfor en un núcleo cuádruple, la ganancia de velocidad será casi lineal para 1-3 núcleos, pero menos si usa 4 núcleos, ya que el último núcleo también necesita ejecutar procesos del sistema.

Por ejemplo, si parfor viene con 100 ms de sobrecarga, y el cálculo en el ciclo tarda 5 ms, y si suponemos que la ganancia de velocidad es lineal hasta 4 núcleos con un coeficiente de 1 (es decirel uso de 4 núcleos hace que el cálculo sea 4 veces más rápido), nt debe ser aproximadamente 30 para que pueda obtener una ganancia de velocidad con parfor (150ms con for, 132ms con parfor). Si tuviera que ejecutar solo 10 iteraciones, parfor sería más lento (50 ms con for, 112ms con parfor).

Puede calcular la sobrecarga de su máquina comparando el tiempo de ejecución con 1 trabajador frente a 0 trabajadores, y puede estimar la ganancia de velocidad haciendo que un revestimiento encaje en los tiempos de ejecución con 1 a 4 trabajadores. Entonces sabrá cuándo es útil usar parfor.

Answer 3

Además del mal funcionamiento debido a la sobrecarga de comunicación (ver otras respuestas), hay otra razón para no usar parfor en este caso. Todo lo que se hace dentro del parfor en este caso usa built-in multithreading. Suponiendo que todos los trabajadores se ejecutan en la misma PC, no hay ventaja porque una sola llamada ya usa todos los núcleos de su procesador.