OpenMP num_hilos (1) se ejecuta más rápido que ningún OpenMP

Question

He ejecutado mi código en una variedad de circunstancias que han resultado en lo que creo que es un comportamiento extraño. Mi prueba fue en un procesador intel xeon de doble núcleo con HT.

No OpenMP '#pragma' declaración, tiempo de ejecución total = 507 segundos

Con OpenMP declaración '#pragma' especificando 1 núcleo, tiempo de ejecución total = 117 segundos

Con #pragma OpenMP' 'declaración que especifique 2 de núcleo, tiempo de funcionamiento total = 150 segundos

Con OpenMP 'declaración #pragma' especificando 3 de núcleo, tiempo de ejecución total = 157 segundos

Con la declaración '#pragma' de OpenMP que especifica 4 núcleos, tiempo de ejecución total = 144 segundos

Supongo que no puedo entender por qué el comentario de mi línea openmp hace que el programa disminuya mucho entre 1 hilo sin abrir y 1 hilo CON openmp.

Todo lo que estoy cambiando es entre:

//#pragma omp parallel for shared(segs) private(i, j, p_hough) num_threads(1) schedule(guided) 

and... 

#pragma omp parallel for shared(segs) private(i, j, p_hough) num_threads(1,2,3,4) schedule(guided) 

De todas formas, si alguien tiene alguna idea de por qué esto puede estar pasando, por favor hágamelo saber!

Gracias por cualquier ayuda,

Brett

EDIT: Voy a abordar algunos de los comentarios aquí

estoy usando NUM_THREADS (1), NUM_THREADS (2), etc ..

Con una mayor investigación, resulta que mis resultados son inconsistentes en función de si la línea "programar (guiada)" está incluida o no en el código.

-Cuando utilizo la línea de programación (guiada), genero la solución más rápida, independientemente del número de subprocesos. -Cuando estoy usando el planificador predeterminado, mis resultados son significativamente más lentos y los valores diferentes -Con la mejora del cronograma (guiado) no se obtiene con hilos aumentados -Sin horario (guiado) aumento con la adición de hilos

Supongo que no he encontrado una descripción suficientemente buena de lo que el cronograma (guiado) hace por mí, entiendo que intente dividir el ciclo para que las iteraciones que requieren más tiempo sucedan primero, lo que debería tener un efecto de la menor cantidad de tiempo que un subproceso espera a que los otros completen sus iteraciones.

Parece que para mi ciclo de iteración ~ 900, cuando uso el cronograma (guiado), solo estoy procesando ~ 200 iteraciones, donde como sin el cronograma (guiado) estoy procesando las 900 iteraciones. ¿Alguna idea?

Answer 1

OpenMP tiene importantes gastos generales de sincronización. He descubierto que a menos que tenga un gran bucle realmente que hace mucho trabajo, y no tiene sincronización dentro del bucle, generalmente no vale la pena usar OpenMP.

Creo que cuando establece el número de subprocesos en uno (1), OpenMP simplemente hace una llamada de procedimiento al procedimiento OpenMP implementando el ciclo, por lo que la sobrecarga es mínima y el rendimiento es esencialmente idéntico al no OpenMP caso.

De lo contrario, creo que OpenMP establece algunos semáforos y los subprocesos de "trabajador" esperando se activan, sincronizan su acceso a las estructuras de datos diciéndoles qué parámetros de ciclo establecer y luego llaman a la rutina que hace el trabajo y cuándo completar el pedazo de trabajo, señalan el hilo maestro nuevamente. Esta sincronización debe ocurrir para cada pedazo de trabajo que hace un hilo, y los costos de sincronización no son triviales.

El uso de la opción de programación STATIC puede ayudar a reducir los gastos generales de programación/sincronización, particularmente si el número de iteraciones de ciclo es grande en relación con el número de núcleos.