Tiene lo básico que se atornilla al paralelismo con partes de un programa. C++ 17 está obteniendo muchos de ellos (por ejemplo, versiones paralelas de foreach, sort, find y friends, map_reduce, map, reduce, prefix_sum ...) ver C++ Extensions for Parallelism
Luego tienes los elementos como continuaciones. Piense en std::future pero con continúa. Hay pocas maneras de implementar esto (boost tiene una buena versión ahora, ya que la estándar no tiene un próximo (...) o luego (...) método, pero la gran ventaja es que uno no tiene que esperar que haga la siguiente tarea
auto fut = async([](){..some work...}).then([](result_of_prev){...more work}).then... ;
fut.wait();
la falta de sincronización entre las tareas posteriores es importante ya que la comunicación entre tareas/hilos/... es lo que ralentiza programas paralelos hacia abajo.
Así que con eso el paralelismo basado en tareas es realmente agradable. Con un planificador de tareas, simplemente pasa las tareas y se aleja. Pueden tener métodos, como un semáforo, para comunicarse, pero eso no es obligatorio. Ambos Intel Thread Building Blocks y Microsoft Parallel Pattern Library tienen fa Cilitudes para esto.
Después de eso tenemos el patrón de tenedor/unión. No implica crear N hilos para cada tarea. Solo que tienes estas N, cosas idealmente independientes, para hacer (fork) y cuando terminan tienen un punto de sincronización en algún lugar (join).
auto semaphore = make_semaphore(num_tasks);
add_task([&semaphore]() {...task1...; semaphore.notify(); });
add_task([&semaphore]() {...task2...; semaphore.notify(); });
...
add_task([&semaphore]() {...taskN...; semaphore.notify(); });
semaphore.wait();
Desde arriba puede comenzar a ver el patrón que se trata de un diagrama de flujo. El futuro es (A >> B >> C >> D) y Fork Join es (A | B | C | D). Con eso puedes combinarlos para formar un gráfico. (A1 >> A2 | B1 >> B2 >> B3 | C1 | D1 >> D2 >> (E1 >> E2 | F1)) Donde A1 >> A2 significa que A1 debe preceder a A2 y A | B significa que A y B puede correr concurrentemente Las partes lentas se encuentran al final de los gráficos/subgrafos donde las cosas se juntan.
El objetivo es encontrar partes independientes del sistema que no necesiten comunicarse. Los algoritmos paralelos, como se señaló anteriormente, son en casi todos los casos más lentos que sus equivalentes secuenciales hasta que la carga de trabajo sea lo suficientemente alta o el tamaño sea lo suficientemente grande (suponiendo que la comunicación no sea demasiado hablador). Por ejemplo, ordenar. En una computadora de 4 núcleos obtendrás alrededor de 2.5X el rendimiento dado o recibido porque la fusión es hablante y requiere mucha sincronización y no funciona todos los núcleos después de la primera ronda de fusión. En una GPU con una N que es muy grande, se puede usar una clase menos eficiente, como Bitonic, y termina siendo muy rápida porque tienes muchos trabajadores para potenciar el trabajo y todos están tranquilos haciendo sus cosas.
Algunos trucos para reducir la comunicación incluyen, usar una matriz de resultados para que cada tarea no intente bloquear un objeto para insertar un valor. A menudo, la reducción de estos resultados puede ser muy rápida.
Pero con todos los tipos de paralelismo la lentitud proviene de la comunicación. Reducirlo.
¿Puede aclarar qué tipo de programación en paralelo le interesa? La programación distribuida usando MPI es considerablemente diferente del paralelismo de nivel de bucle usando OpenMP. – mch
Estoy particularmente interesado en los patrones generales y las expresiones idiomáticas en la programación paralela, ya sea con memoria distribuida o modelos de memoria compartida en una sola máquina o varias máquinas. –