¿Qué API de programación en paralelo usa?

Question

Tratando de comprender cómo las personas escriben códigos paralelos en la actualidad, considerando la inmensa importancia del hardware multinúcleo y de multiprocesamiento actualmente. Para mí, parece que el paradigma dominante es pthreads (hilos POSIX), que es nativo en Linux y está disponible en Windows. Las personas de HPC tienden a usar OpenMP o MPI, pero parece que no hay muchos aquí en StackOverflow. ¿O confía en el enhebrado de Java, las API de enhebrado de Windows, etc. en lugar de los estándares portátiles? ¿Cuál es la forma recomendada, en su opinión, para hacer programación paralela?

¿O está usando cosas más exóticas como Erlang, CUDA, RapidMind, CodePlay, Oz o incluso querida vieja Occam?

Aclaración: Estoy buscando soluciones que sean bastante portátiles y aplicables a plataformas como Linux, varias Unixes, en varias arquitecturas de host. Windows es un caso raro que es agradable de soportar. Entonces, C# y .net son muy limitados aquí, el CLR es una genial tecnología, pero PODRÍAN SACARLO para el host de Linux, para que sea tan frecuente como JVM, Python, Erlang o cualquier otro lenguaje portátil.

C++ o basado en JVM: probablemente C++, ya que las JVM tienden a ocultar el rendimiento.

MPI: Estoy de acuerdo en que incluso las personas de HPC lo ven como una herramienta difícil de usar, pero para ejecutar en 128000 procesadores, es la única solución escalable para los problemas donde no se aplican mapas/reducciones. Sin embargo, el paso de mensajes tiene una gran elegancia, ya que es el único estilo de programación que parece escalar muy bien a la memoria local/AMP, memoria compartida/SMP, entornos distribuidos de tiempo de ejecución.

Un nuevo contendiente interesante es el MCAPI. pero no creo que nadie haya tenido tiempo para tener ninguna experiencia práctica con eso todavía.

Así que, en general, la situación parece ser que hay muchos proyectos interesantes de Microsoft que no conocía, y que la API o pthreads de Windows son las implementaciones más comunes en la práctica.

Answer 1

Hemos empezado a buscar en parallel extensions de Microsoft; aún no se ha publicado, pero sin duda muestra su potencial.

Answer 2

He utilizado ACE para permitir a los desarrolladores utilizar el estilo POSIX (o Windows) en cualquier plataforma.

Answer 3

Parallel FX Library (PFX) - una biblioteca de concurrencia administrada desarrollada por una colaboración entre Microsoft Research y el equipo de CLR en Microsoft para su inclusión con una futura revisión de .NET Framework. Está compuesto de dos partes: Parallel LINQ (PLINQ) y Task Parallel Library (TPL). También consiste en un conjunto de estructuras de datos de coordinación (CDS): un conjunto de estructuras de datos utilizadas para sincronizar y coordinar la ejecución de tareas concurrentes. La biblioteca fue lanzado como un CTP el 29 de noviembre de 2007 y actualiza de nuevo en diciembre de 2007 y junio de 2008.

No mucho experiencia, sin embargo ...

Answer 4

Para .Net he utilizado con gran éxito RetLang. Para JVM, Scale es genial.

Answer 5

Recomendaría OpenMP. Microsoft lo ha incluido en el compilador de Visual C++ 2005, por lo que es compatible, y no necesita hacer nada más que compilar con la directiva/omp.

Es fácil de usar, aunque obviamente no hace todo por usted, pero nada lo hace.Lo uso para correr en paralelo para bucles en general sin ningún tipo de molestia, para cosas más complejas que tienden a rodar el mío (por ejemplo, tengo código de hace años que corté, pegué y modifiqué).

Puede probar Cilk++ que se ve bien, y tiene un e-book "How to Survive the Multicore Software Revolution".

Ambos tipos de sistema intentan paralelizar el código de serie, es decir, tomar un ciclo para ejecutarlo en todos los núcleos simultáneamente de la manera más fácil posible. No tienden a ser bibliotecas de hilos de propósito general. (por ejemplo, un research paper (pdf) describió el rendimiento de diferentes tipos de grupos de subprocesos implementados en openMP y sugirieron que se deben agregar 2 operaciones nuevas - ceder y dormir. Creo que están perdiendo el punto de OpenMP un poco allí)

Como mencionaste OpenMP, supongo que estás hablando de C++ nativo, no de C# o .NET.

Además, si las personas de HPC (que supongo que son expertos en este tipo de dominio) parecen estar usando OpenMP o MPI, entonces esto es lo que deberían usar, ¡no lo que los lectores de SO son!

Answer 6

Tenga en cuenta que las respuestas aquí no serán una respuesta estadísticamente representativa de "usar realmente". Ya veo una cantidad de respuestas "X es agradable".

He utilizado personalmente Windows Threads en muchos proyectos. La otra API que he visto en amplio uso es pthreads. En el frente de HPC, MPI todavía se toma en serio por las personas que lo usan <subjective> No lo hago - combina toda la elegancia de C++ con el rendimiento de Javascript. Sobrevive porque no hay una alternativa decente. Perderá con las máquinas NUMA estrechamente acopladas en un lado y con el mapa al estilo Google, por el otro. </subjective>

Answer 7

1 de PLINQ

Win32, Hilos y fibras, Threadpool sincronización Objetos

Answer 8

Más Data Parallel Haskell estaría bien, pero incluso sin él, GHC> 6.6 tiene cierta capacidad impresionante para paralelizar algoritmos fácilmente, a través de Control.Parallel.Strategies.

Answer 9

que mantienen un enlace del blog de concurrencia que ha cubierto un montón de ellos en el tiempo (y continuará haciéndolo):

http://concurrency.tumblr.com

Answer 10

MPI no es tan difícil como la mayoría lo hacen parecer. Hoy en día, creo que un enfoque multi-paradigma es más adecuado para aplicaciones paralelas y distribuidas. Use MPI para su nodo a la comunicación y sincronización de nodos y OpenMP o PThreads para su paralelización más granular. Piense en MPI para cada máquina y OpenMP o PThreads para cada núcleo. Esto parece escalar un poco mejor que generar un nuevo MPI Proc para cada núcleo en el futuro cercano.

Quizás para dual o quad core en este momento, generar un proc para cada núcleo en una máquina no tendrá mucha sobrecarga, pero a medida que nos acerquemos a más núcleos por máquina donde la caché y la memoria no están escalando tanto, sería más apropiado usar un modelo de memoria compartida.

Answer 11

¿Qué tal Open CL?

Answer 12

Sólo sé lo que va de Java, soporte multi threading no funcionó bien para mí ..

Answer 13

depende mucho de su entorno.

Para palin old C nada mejor que POSIX.

Para C++ hay una biblioteca de threading muy buena de BOOST.ORG gratis.

Java solo utiliza el enrutamiento nativo de Java.

También puede buscar otras maneras de lograr el paralelismo que no sea el de subprocesamiento, como dividir la aplicación en los procesos del cliente y del servidor y usar la mensajería asíncrona para comunicarse. Hecho correctamente, esto puede escalar hasta miles de usuarios en docenas de servidores.

También vale la pena recordar que si está utilizando Windows MFC, entorno de ventanas Gnome o Qt, se encuentra automáticamente en un entorno multiproceso. Si está utilizando Apache ISS o J2EE, su aplicación ya se está ejecutando dentro de un entorno multiproceso multiproceso.

Answer 14

Utilicé OpenMP mucho principalmente debido a su simplicidad, portabilidad y flexibilidad. Es compatible con varios idiomas incluso todopoderoso C++/Cli :)

Answer 15

Uso MPI y me gusta mucho. Te obliga a pensar en la jerarquía de la memoria, pero en mi experiencia, pensar en tales cosas es importante para el alto rendimiento de todos modos. En muchos casos, MPI puede ocultarse en gran medida detrás de objetos paralelos específicos del dominio (por ejemplo, PETSc para resolver ecuaciones lineales y no lineales).

Answer 16

La mayoría de los programas simultáneos que he escrito estaban en Ada, que tiene soporte completo para el paralelismo nativo en el idioma. Una de las mejores ventajas de esto es que su código paralelo es portátil para cualquier sistema con un compilador Ada. No se requiere una biblioteca especial.

Answer 17

pycuda ... nada como 25000 hilos activos :) [warp planned with marcador]. cuda 2 tiene soporte de flujo, así que no estoy seguro de qué streamit traería. Las extensiones de CUDA Matlab se ven bien, al igual que PLUTO y las próximas PetaBricks de MIT.

por lo que respecta a otros, falta el enhebrado de python; MPI, etc. son complicados, y no tengo un clúster, pero supongo que logran para lo que están diseñados; Paré la programación de C# antes de llegar a los apartamentos de la secuencia (probablemente algo bueno).

Answer 18

No es paralelo per se y no tiene un modelo distribuido, pero puede escribir código altamente concurrente en la JVM usando Clojure. A continuación, obtiene la gran cantidad de bibliotecas de Java disponibles para usted. Tendría que implementar sus propios paralelos en la parte superior de Clojure, pero eso debería ser relativamente fácil. Repito que no tiene pero tiene un modelo distribuido.

Answer 19

ghreads de la biblioteca glibc http://library.gnome.org/devel/glib/stable/glib-Threads.html compila hasta pthreads, para que no pierdas ningún rendimiento. También le ofrecen grupos de subprocesos muy potentes y colas de mensajes entre subprocesos. Los he usado con éxito varias veces, y estoy muy contento con las funciones disponibles.

Answer 20

Uso open cl.Creo que es bastante más fácil de usar en comparación con mpi.También he usado mpi antes como un requisito para mi curso de computación paralela y distribuida, pero creo que tienes que hacer demasiado trabajo manual.I Voy a comenzar a trabajar en CUDA en unos días. CUDA es muy similar a open cl pero el problema es que CUDA es solo para productos de nvidia.