Limites du calcul parallèle


21

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?



Oui, cela semble raisonnable. Un chapitre du livre Computational Complexity de Papadimitriou donne une bonne explication pour apprendre ce sujet.
Tsuyoshi Ito du

Réponses:


17

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.


Il est certain que vous ne pourrez peut-être pas paralléliser une partie donnée d'une requête de base de données, ou du moins d'une manière simple. Cependant, une requête de base de données (excluant les sous-requêtes pour simplifier les choses) peut être réduite à une analyse complète de la table sur une table jointe, et cette table jointe elle-même peut toujours être analysée en parallèle. C'est pourquoi, lorsque vous augmentez les paramètres de parallélisme dans Oracle, il est plus enclin à utiliser des analyses de table complètes plutôt que des index.
sclv

@sclv: C'est vrai, mais en général les jointures intermédiaires peuvent être exponentielles dans la taille d'entrée? On peut donc paralléliser via des jointures, mais au prix d'avoir à scanner un nombre exponentiel de tuples.
András Salamon

1
Que pensez-vous de la taille d'entrée ici? En outre, si vous avez un m n o cross-join, il y a toujours la possibilité que vous pourriez revenir précisément que beaucoup de tuples - dire qu'il n'y a pas de possible mieux lié au pire des cas. Et cela est plus pratique que théorique, mais en général, vous ne vous inquiétez pas de paralléliser les performances d'un prédicat sur une ligne de toute façon, mais du débit d'E / S, car c'est là que la limite aura tendance à être.
sclv

10

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.


2
Il faut se méfier. Je ne pense pas que l'appariement soit complet. L'appariement est connu pour être en RNC par des tests d'identité polynomiale (tester si le déterminant de la matrice de Tutte du graphique est identique à zéro). S'il était P-complet, alors l'effondrement improbable P = RNC s'ensuivrait.
slimton

argh. tu as raison. J'aurais dû m'en tenir aux débits max. Merci pour la correction.
Suresh Venkat

0

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.)

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.