Limites du calcul parallèle

Je suis curieux au sens large de ce que l'on sait des algorithmes de parallélisation en P. J'ai trouvé l'article wikipedia suivant sur le sujet:

http://en.wikipedia.org/wiki/NC_%28complexity%29

L'article contient la phrase suivante:

On ne sait pas si NC = P, mais la plupart des chercheurs soupçonnent que cela est faux, ce qui signifie qu'il existe probablement des problèmes traitables qui sont "intrinsèquement séquentiels" et ne peuvent pas être accélérés de manière significative en utilisant le parallélisme.

Cela vous semble-t-il raisonnable? Existe-t-il des cas connus où un problème dans P ne peut pas être accéléré en utilisant le parallélisme?

On ne sait même pas si NC = P, mais les problèmes P-complets semblent intrinsèquement difficiles à paralléliser. Il s'agit notamment de la programmation linéaire et du Horn-SAT. (En revanche, les problèmes dans NC semblent assez faciles à paralléliser.)

Voir la question Problèmes entre NC et P: combien ont été résolus à partir de cette liste? pour des documents de référence (y compris des liens vers un manuel classique qui est maintenant disponible en téléchargement gratuit), et une discussion plus approfondie sur les problèmes qui sont en P mais qui ne sont pas connus pour être parallélisables.

Voir la question Théorème de Ladner généralisé pour la structure des classes de complexité entre NC et P. En bref, si elles diffèrent, il existe une infinité de classes de complexité strictement entre NC et P.

Voir question NC = conséquences P? pour une belle démonstration de Ryan Williams qu'il est possible d'amplifier les effondrements dans la hiérarchie des classes de complexité au sein de P en effondrements peut-être plus improbables comme PSPACE = EXP .

Il convient de souligner qu'une des conséquences de Horn-SAT étant P-complete, et des liens ci-dessus, est qu'il ne semble pas possible de paralléliser les requêtes SQL générales dans les bases de données, sauf si nous pouvons également réécrire tout calcul à grande échelle à utiliser uniquement une quantité raisonnable de stockage. Il s'agit d'une divergence déroutante - je pense qu'il est assez controversé d'affirmer qu'il existe des limites à la compression , mais je vois souvent des articles qui semblent construits sur l'hypothèse qu'il est possible de paralléliser n'importe quelle requête de base de données.

Eh bien, s'il y avait des cas connus, nous pourrions alors séparer P et NC. Mais il existe de nombreux problèmes connus pour être P-complet (c'est -à- dire dans le cadre des réductions de l'espace de log), et ils présentent le même type d'obstacles à l'affichage de P = NC que les problèmes NP-complets pour P = NP. Parmi eux, la programmation linéaire et l' appariement (et les flux max en général).

Ketan Mulmuley a prouvé un résultat séparant P et une forme faible de NC (sans opérations de bits) en 1994. Dans un sens, son programme actuel pour P vs NP décolle de là où il s'était arrêté ( de manière très lâche ).

Le livre « Limits on Parallel Computation » en dit plus.

J'ai répondu à la question similaire Y a-t-il des problèmes / algorithmes célèbres dans le calcul scientifique qui ne peuvent pas être accélérés par la parallélisation sur le site Computational Science . Permettez-moi de le citer ici, car il offre une perspective pratique sur un exemple très concret d'un tel problème:

La (célèbre) méthode de marche rapide pour résoudre l'équation Eikonal ne peut pas être accélérée par la parallélisation. Il existe d'autres méthodes (par exemple des méthodes de balayage rapide) pour résoudre l'équation Eikonal qui se prêtent mieux à la parallélisation, mais même ici, le potentiel d'accélération (parallèle) est limité.

Le problème avec l'équation Eikonal est que le flux d'informations dépend de la solution elle-même. En gros, les informations circulent le long des caractéristiques (c'est-à-dire les rayons lumineux en optique), mais les caractéristiques dépendent de la solution elle-même. Et le flux d'informations pour l'équation Eikonale discrétisée est encore pire, nécessitant des approximations supplémentaires (comme implicitement présentes dans les méthodes de balayage rapide) si une accélération parallèle est souhaitée.

Pour voir les difficultés de la parallélisation, imaginez un joli labyrinthe comme dans certains des exemples de la page Web de Sethian . Le nombre de cellules sur le chemin le plus court à travers le labyrinthe (probablement) est une limite inférieure pour le nombre minimal d'étapes / itérations de tout algorithme (parallèle) résolvant le problème correspondant.

(J'écris "(probablement)", car les limites inférieures sont notoirement difficiles à prouver et nécessitent souvent des hypothèses raisonnables sur les opérations utilisées par un algorithme.)