Estoy creando una aplicación de subprocesos múltiples en C que usa Linux.Pthreads vs. OpenMP
No estoy seguro de si debería utilizar la API de subprocesos POSIX o la API de OpenMP.
¿Cuáles son los pros & contras del uso de cualquiera de los dos?
Editar:
Podría alguien aclarar si ambas API crean nivel de kernel o usuario de nivel hilos?
Pthreads y OpenMP representan dos paradigmas de multiprocesamiento totalmente diferentes.
Pthreads es una API de muy bajo nivel para trabajar con subprocesos. Por lo tanto, tiene un control extremadamente fino sobre la gestión de subprocesos (create/join/etc), mutexes, etc. Es bastante básico.
Por otro lado, es OpenMP mucho más alto nivel, es más portátil y no lo limita a la utilización de C. También se redujo mucho más fácilmente que pthreads. Un ejemplo específico de esto son las construcciones de trabajo compartido de OpenMP, que le permiten dividir el trabajo en varios hilos con relativa facilidad. (Ver también Wikipedia pros and cons list.)
Dicho esto, realmente no proporcionó ningún detalle sobre el programa específico que está implementando, o cómo planea usarlo, por lo que es bastante imposible recomendar una API sobre la otra.
Si usa OpenMP, puede ser tan simple como agregar un solo pragma, y usted será el 90% del camino al código correctamente multiproceso con aceleración lineal. Para obtener el mismo aumento de rendimiento con pthreads toma mucho más trabajo.
Pero, como siempre, obtiene más flexibilidad con pthreads.
Básicamente, depende de cuál sea su aplicación. ¿Tienes un algoritmo trivialmente paralelo? ¿O simplemente tienes muchas tareas arbitrarias que te gustaría realizar simultáneamente? ¿Cuánto necesitan las tareas para hablar entre ellas? ¿Cuánta sincronización se requiere?
Respondiendo preguntas con preguntas ... tsk;) Sería genial si aclaras cómo las respuestas a esas preguntas realmente afectan la decisión utilizar pthreads vs OpenMP. –
OpenMP tiene la ventaja de ser multiplataforma y más simple para algunas operaciones. Maneja el roscado de una manera diferente, ya que le da opciones de mayor nivel de roscado, como paralelización de bucles, tales como:
#pragma omp parallel for
for (i = 0; i < 500; i++)
arr[i] = 2 * i;
Si esto le interesa, y si C++ es una opción, también me recomendar Threading Building Blocks.
Pthreads es una API de nivel inferior para generar subprocesos y sincronizar explícitamente. En ese sentido, proporciona más control.
Los hilos POSIX, que forman parte del estándar POSIX, son multiplataforma. OpenMP, que no está presente en ningún sistema operativo o estándar de lenguaje C que yo sepa, no es multiplataforma, a menos que tenga una idea realmente extraña de lo que significa multiplataforma. –
@R. - OpenMP es de hecho multiplataforma, incluso si no está formalmente estandarizado, con C++ y C API. cf. Impulse en el mundo C++, no es un estándar de jure, sino un estándar de facto. –
@R ..: No estoy seguro de lo que quiere decir, el estándar OpenMP C API está disponible en esta especificación (http://www.openmp.org/mp-documents/cspec20.pdf). A menos que quisieras decir, no estandarizado por IEEE/ANSI/ISO? – TechZilla
Depende de 2 cosas: su código base y su lugar dentro de él. Las preguntas clave son: 1) "¿La base del código tiene subprocesos, grupos de subprocesos y las primitivas de control (bloqueos, eventos, etc.)" y 2) "¿Está desarrollando bibliotecas reutilizables o aplicaciones normales?"
Si su biblioteca tiene herramientas de subprocesos (casi siempre se basan en cierto sabor de PThread), USE ESOS. Si es un desarrollador de biblioteca, dedique el tiempo (si es posible) para construirlos.Vale la pena: puedes armar mucho más fino y avanzado que el que OpenMP te dará.
Por el contrario, si está presionado por el tiempo o simplemente el desarrollo de aplicaciones o algo fuera de las herramientas de terceros, utilice OpenMP. Puede envolverlo en algunas macros y obtener el paralelismo básico que necesita.
En general, OpenMP es lo suficientemente bueno para multi-threading básico. Una vez que empiezas a llegar al punto de que estás administrando los recursos del sistema directamente en la creación de un código altamente asincrónico, su ventaja de facilidad de uso se ve obstaculizada por problemas de rendimiento y de interfaz.
Re: su edición (núcleo o nivel de usuario?) - ¡Depende de la implementación! Una API es solo eso, una ** interfaz **. OpenMP no es la implementación, [pero estas son algunas implementaciones] (http://en.wikipedia.org/wiki/OpenMP#Implementations). (Hay un poco de información en [este artículo de Wikipedia, también] (http://en.wikipedia.org/wiki/Native_POSIX_Thread_Library)). –
Básicamente, si puede hacer lo que necesita en OpenMP, debe hacerlo en OpenMP. –
OpenMP se debe usar para bucles que deben computarse en todos los núcleos. PThread también puede hacer eso, pero eso es mucho trabajo y es muy difícil de mantener, normalmente usas PThread si necesitas comenzar un proceso separado que no debería bloquear el hilo principal. Por ejemplo: tiene un servidor, los clientes se conectan y tiene que mantener la conexión con el servidor y hablar con él, crea un hilo por cliente y trabaja con el cliente en ese hilo sin bloquear el hilo principal. Es como crear una nueva aplicación y dejarla funcionar en el sistema operativo sin molestar a la aplicación principal. –