GNU Parallel peut-il exécuter plus de process parallèles?

Non seulement c'est possible; il est également recommandé dans certaines situations.

GNU Parallel prend environ 10 ms pour exécuter un travail. Donc, si vous avez 8 cœurs et que les tâches que vous exécutez prennent less de 70 ms, vous verrez que GNU Parallel utilise 100% d'un seul core, et qu'il y aura du time mort sur les autres cœurs. Ainsi, vous n'utiliserez pas 100% de tous les cœurs.

L'autre situation où il est recommandé est si vous voulez exécuter plus de tâches que -j0 fera. Actuellement -j0 tournera environ 250 emplois en parallèle à less que vous ne -j0 certaines limites du système. Il est parfaitement logique d'exécuter plus de 250 tâches si les tâches ne sont pas limitées par le processeur et les E / S disque. C'est par exemple vrai si la latence réseau est le facteur limitant.

Cependant, l'utilisation de 2 lists n'est pas recommandée pour séparer les tâches. La méthode recommandée consiste à utiliser GNU Parallel pour appeler GNU Parallel:

 cat list0 | parallel -j20 --pipe parallel -j100 

Cela permettra de gérer 2000 emplois en parallèle. Pour exécuter plus ajuster -j . Il est recommandé que l'extérieur (le 20) soit au less le nombre de coeurs, de sorte qu'il y ait au less un process GNU parallèle sur chaque kernel.

En utilisant cette technique, vous devriez avoir aucun problème à démarrer 20000 emplois en parallèle; quand vous obtenez plus de 32000 process, les choses commencent à agir.

Je ne vois pas pourquoi cela ne serait pas possible – le système peut certainement jongler avec 200 tâches parallèles.

Cependant, cela n'est certainement pas souhaitable, à less qu'il n'y ait une raison spécifique pour laquelle vous avez besoin du nombre exact de tâches exécutées en parallèle. Cela semble peu probable; la seule raison que je pourrais voir serait parce que vous avez besoin d'eux tous en même time parce qu'ils ont besoin d'échanger des informations ou d'échanger des informations avec quelque chose d'autre de façon chaotique et indéterminée.

La raison pour laquelle il n'est pas autrement souhaitable est que l'état idéal, en termes d'efficacité, est que le système exécute un nombre de process égal au nombre de cœurs de processeur disponibles. Dans la mesure où les process impliquent souvent des goulets d'étranglement en dehors de la CPU (par ex. E / S disque), ce nombre idéal généralisé varie en fonction du nombre de cœurs + 1 jusqu'au nombre de cœurs * 2.

La raison pour laquelle il s'agit de l'efficacité de l'état idéal est que si une tâche consum 1 million d'unités de time processeur, exécuter la même tâche 10 fois de manière séquentielle consum 10 millions d'unités et exécute la même tâche en parallèle consum 10 millions d'unités. Cependant, dans ce dernier cas, s'il y a less de 10 CPU, il y a un coût supplémentaire car le système doit constamment passer d'une tâche à l'autre.

C'est aussi pourquoi un système avec 2 kernelx 2 Ghz est généralement plus rapide qu'un système avec 4 kernelx 1 Ghz. La principale raison de l'évolution des systèmes multicœurs est qu'il devient de plus en plus difficile de fabriquer des processeurs de plus en plus rapides, et au-delà d'un certain point relativement bas, c'est impossible. La solution consiste donc à fabriquer des systèmes avec plus de cœurs de processeur.

Bref, si vous devez faire 20 choses le plus rapidement possible et que vous avez 4 coeurs, le moyen le plus rapide est de les faire en 5 séries de 4 ou 4 séries de 5 pour permettre le time d'attente E / S. parallel vous permet de lui donner une list de longueur indéfinie tout en limitant le nombre de tâches en même time (et notez que le nombre par défaut est le nombre de cœurs).

Il y a une sorte d'exception à cela, bien que cela concerne généralement certains types de programmes multi-thread singuliers (c'est-à-dire pas un set de programmes séparés, mais un programme qui occupe plusieurs cœurs). En effet, lorsqu'un programme peut accomplir quelque chose en le faisant avec des twigs relativement indépendantes qui n'ont besoin de coordonner qu'occasionnellement («occasionnellement» peut être aussi fréquent que 10 ou 20 fois par seconde), c'est beaucoup plus facile et souvent plus flexible , de concevoir le programme pour le faire dans des threads indépendants plutôt que de le concevoir pour faire circuler les tâches de manière arbitraire (asynchronous). Les programmes graphiquement intenses et / ou interactifs tels que les jeux video et les systèmes de CAO entrent dans cette catégorie.