Comment tirez-vous parti de Multicore ?

Question

En tant que personne dans le monde de HPC Venu du monde du développement web d'entreprise, je suis toujours curieux de voir comment les développeurs du "monde réel" tirent parti du calcul parallèle. C'est d'autant plus pertinent maintenant que toutes les puces deviennent multicore Il sera encore plus pertinent lorsqu'il y aura des milliers de cœurs sur une puce et non plus seulement quelques-uns.

Mes questions sont les suivantes :

1. Comment cela affecte-t-il votre feuille de route logicielle ?
2. Je suis particulièrement intéressé par les histoires réelles sur la façon dont le multicore affecte différents domaines logiciels, alors précisez le type de développement que vous faites dans votre réponse ( par exemple côté serveur, applications côté client, calcul scientifique, etc.)
3. Que faites-vous avec votre code existant pour tirer parti des machines multicœurs, et quels défis avez-vous rencontrés ? Utilisez-vous OpenMP , Erlang , Haskell , CUDA , TBB , CUP ou autre chose ?
4. Que prévoyez-vous de faire lorsque les niveaux de concurrence continueront à augmenter, et comment allez-vous gérer des centaines ou des milliers de cœurs ?
5. Si votre domaine n'a pas bénéficient facilement du calcul parallèle, alors expliquer pourquoi est également intéressant.

Enfin, j'ai formulé cette question comme une question sur le multicœur, mais n'hésitez pas à parler d'autres types de calcul parallèle. Si vous portez une partie de votre application pour utiliser MapReduce ou si MPI sur de grands clusters est le paradigme pour vous, alors mentionnez-le également.

Mise à jour : Si vous répondez #5, dites si vous pensez que les choses changeront s'il y a plus de cœurs (100, 1000, etc.) que vous ne pouvez alimenter avec la bande passante mémoire disponible (étant donné que la bande passante est de plus en plus petite par cœur). Pouvez-vous toujours utiliser les cœurs restants pour votre application ?

Answer 1

Mes travaux de recherche comprennent des travaux sur les compilateurs et sur le filtrage du spam. Je fais également beaucoup de travaux Unix de "productivité personnelle". En outre, j'écris et j'utilise des logiciels pour administrer les cours que je donne, ce qui inclut la notation, le test du code des étudiants, le suivi des notes et une myriade d'autres choses.

1. Le multicore ne m'affecte pas du tout sauf comme un problème de recherche pour les compilateurs afin de supporter d'autres applications. Mais ces problèmes se situent principalement dans le système d'exécution, et non dans le compilateur.
2. À grands frais, Dave Wortman a montré vers 1990 que l'on pouvait paralléliser un compilateur pour occuper quatre processeurs . Personne que je connais n'a jamais répété l'expérience. La plupart des compilateurs sont assez rapides pour fonctionner en mode monofilaire. Et il est beaucoup plus facile d'exécuter votre compilateur séquentiel sur plusieurs fichiers sources différents en parallèle que de rendre votre compilateur lui-même parallèle. Pour le filtrage du spam, l'apprentissage est un processus intrinsèquement séquentiel . Et même une machine plus ancienne peut apprendre des centaines de messages par seconde, de sorte que même un grand corpus peut être appris en moins d'une minute. Encore une fois, la formation est assez rapide .
3. La seule façon significative que j'ai d'exploiter les machines parallèles est en utilisant la fabrication parallèle . C'est un grand bienfait, et les grosses constructions sont faciles à paralléliser . Make fait presque tout le travail automatiquement. La seule autre chose dont je me souvienne, c'est l'utilisation du parallélisme pour chronométrer un code étudiant de longue durée en le confiant à un groupe de machines de laboratoire, ce que je pouvais faire en toute bonne conscience parce que je n'utilisais qu'un seul cœur par machine, donc seulement 1/4 des ressources du CPU. Oh, et j'ai écrit un script Lua qui utilisera les 4 coeurs lors de l'extraction de fichiers MP3 avec lame. Ce script a demandé beaucoup de travail pour être bien fait.
4. Je vais ignorer des dizaines, des centaines et des milliers de cœurs . La première fois qu'on m'a dit "les machines parallèles arrivent, vous devez vous préparer", c'était en 1984. C'était vrai alors et c'est encore vrai aujourd'hui que la programmation parallèle est un domaine réservé à des spécialistes hautement qualifiés . La seule chose qui a changé est qu'aujourd'hui Les fabricants nous forcent à payer pour du matériel parallèle. que nous le voulions ou non. Mais Ce n'est pas parce que le matériel est payant qu'il est gratuit à utiliser. Les modèles de programmation sont horribles, et rendre le modèle thread/mutex travail sans parler des performances, est un travail coûteux, même si le matériel est gratuit. Je m'attends à ce que la plupart des programmeurs ignorent le parallélisme et vaquent tranquillement à leurs occupations. Lorsqu'un spécialiste compétent présentera un logiciel parallèle ou un jeu vidéo génial, j'applaudirai discrètement et j'utiliserai ses efforts. Si je veux des performances pour mes propres applications, je me concentrerai sur les points suivants réduire les allocations de mémoire et ignore le parallélisme.
5. Parallélisme est vraiment difficile. Le plus Les domaines sont difficiles à paralléliser. Une exception largement réutilisable comme le parallel make est une raison de se réjouir.

Résumé (que j'ai entendu de la bouche d'un orateur qui travaille pour un grand fabricant de processeurs) : l'industrie a reculé devant le multicore parce qu'elle ne pouvait pas continuer à faire tourner les machines de plus en plus vite et qu'elle ne savait pas quoi faire avec les transistors supplémentaires. Aujourd'hui, ils cherchent désespérément à trouver un moyen de rendre le multicore rentable, car s'ils ne font pas de bénéfices, ils ne peuvent pas construire la prochaine génération de lignes de fabrication. Le train de la rentabilité est terminé, et nous devrons peut-être commencer à prêter attention aux coûts des logiciels.

De nombreuses personnes qui s'intéressent sérieusement au parallélisme ignorent ces machines jouet à 4, voire 32 cœurs, au profit de GPU à 128 processeurs ou plus. À mon avis, c'est là que les choses vont vraiment bouger.

Answer 2

Pour les applications web, c'est très, très facile : ignorez-les. À moins que vous n'ayez du code qui ne demande qu'à être exécuté en parallèle, vous pouvez simplement écrire du code monofilaire à l'ancienne et être heureux.

Vous avez généralement beaucoup plus de demandes à traiter à un moment donné que de cœurs. Et comme chacune d'entre elles est traitée dans son propre thread (ou même processus, selon votre technologie), vous travaillez déjà en parallèle.

Le seul endroit où vous devez être prudent est lorsque vous accédez à une sorte d'état global qui nécessite une synchronisation. Gardez cela au minimum pour éviter d'introduire des goulots d'étranglement artificiels dans un monde par ailleurs (presque) parfaitement évolutif.

Donc, pour moi, le multi-core se résume essentiellement à ces éléments :

• Mes serveurs ont moins de "CPU" alors que chacun d'entre eux possède plus de cœurs (pour moi, la différence n'est pas énorme).
• Le même nombre de processeurs peut supporter un plus grand nombre d'utilisateurs simultanés.
• Quand le goulot d'étranglement de la performance semble être pas le résultat d'un CPU chargé à 100%, alors c'est une indication que je fais une mauvaise synchronisation quelque part.

Answer 3

1. Pour le moment, ça ne l'affecte pas tant que ça, pour être honnête. Je suis plutôt en " phase de préparation ", en train d'apprendre les technologies et les caractéristiques du langage qui rendent cela possible.
2. Je n'ai pas de domaine particulier, mais j'ai rencontré des domaines comme les mathématiques (où le multi-cœur est essentiel), le tri/recherche de données (où la division et la conquête sur le multi-cœur sont utiles) et les exigences du multi-ordinateur (par exemple, une exigence que la puissance de traitement d'une station de secours est utilisé pour quelque chose).
3. Cela dépend de la langue dans laquelle je travaille. Évidemment, en C#, j'ai les mains liées avec une implémentation pas encore prête des Parallel Extensions qui semble améliorer les performances, jusqu'à ce que vous commenciez à comparer les mêmes algorithmes avec OpenMP (peut-être pas une comparaison juste). Donc, en .NET, ce sera une promenade facile avec quelques outils de gestion de la qualité. for → Parallel.For les refactorings et autres.
   Où les choses deviennent vraiment L'aspect le plus intéressant est le C++, car les performances que l'on peut tirer de choses comme OpenMP sont stupéfiantes par rapport à .NET. En fait, OpenMP m'a beaucoup surpris, car je ne m'attendais pas à ce qu'il fonctionne aussi efficacement. Je suppose que ses développeurs ont eu beaucoup de temps pour le peaufiner. J'apprécie également le fait qu'il soit disponible dans Visual Studio en version prête à l'emploi, contrairement à TBB pour lequel il faut payer.
   En ce qui concerne MPI, j'utilise PureMPI.net pour des petits projets à domicile (j'ai un réseau local) pour faire des calculs qu'une machine ne peut pas tout à fait prendre en charge. Je n'ai jamais utilisé MPI commercialement, mais je sais que MKL a quelques fonctions optimisées pour MPI, qui pourraient être intéressantes à regarder pour ceux qui en ont besoin.
4. J'ai l'intention de faire du "calcul frivole", c'est-à-dire d'utiliser des cœurs supplémentaires pour le précalcul de résultats qui pourraient ou non être nécessaires - si la RAM le permet, bien sûr. J'ai également l'intention de me plonger dans des algorithmes et des approches coûteux que les machines de la plupart des utilisateurs finaux ne peuvent pas gérer actuellement.
5. Quant aux domaines qui ne bénéficient pas de la parallélisation... eh bien, on peut toujours trouver quelque chose. Une chose que je Je suis Ce qui me préoccupe, c'est un support décent dans .NET, bien que j'aie malheureusement abandonné l'espoir d'atteindre des vitesses similaires à celles du C++.

Answer 4

Je travaille dans le domaine de l'imagerie médicale et du traitement des images.

Nous gérons les cœurs multiples de la même manière que les cœurs uniques - nous avons déjà plusieurs threads dans les applications que nous écrivons afin d'avoir une interface utilisateur réactive.

Cependant, puisque nous le pouvons maintenant, nous envisageons de mettre en œuvre la plupart de nos opérations de traitement d'images dans CUDA ou OpenMP. Le compilateur Intel fournit beaucoup de bons exemples de code pour OpenMP, et c'est un produit beaucoup plus mature que CUDA, avec une base installée beaucoup plus importante, donc nous allons probablement opter pour cela.

Ce que nous avons tendance à faire pour les opérations coûteuses (c'est-à-dire plus d'une seconde), c'est de les transférer dans un autre processus, si possible. De cette façon, l'interface utilisateur principale reste réactive. Si ce n'est pas le cas, ou si c'est tout simplement trop gênant ou trop lent de déplacer autant de mémoire, l'opération reste dans un thread, et cette opération peut elle-même engendrer plusieurs threads.

L'essentiel pour nous est de nous assurer que nous ne rencontrons pas de goulots d'étranglement en matière de concurrence. Nous développons en .NET, ce qui signifie que les mises à jour de l'interface utilisateur doivent être effectuées à partir d'un appel Invoke à l'interface utilisateur afin que le thread principal mette à jour l'interface utilisateur.

Je suis peut-être paresseux, mais je ne veux vraiment pas avoir à passer trop de temps à comprendre beaucoup de ces choses lorsqu'il s'agit de paralléliser des choses comme les inversions de matrices et autres. Beaucoup de gens très intelligents ont passé beaucoup de temps à rendre ces choses rapides comme de l'azote, et je veux juste prendre ce qu'ils ont fait et l'appeler. Quelque chose comme CUDA a une interface intéressante pour le traitement d'images (bien sûr, c'est pour cela qu'il est défini), mais il est encore trop immature pour ce genre de programmation plug-and-play. Si moi ou un autre développeur avons beaucoup de temps libre, nous pourrions faire un essai. Au lieu de cela, nous nous contenterons d'utiliser OpenMP pour accélérer notre traitement (et c'est certainement sur la feuille de route du développement pour les prochains mois).

Answer 5

Je développe des applications web ASP.NET. Il n'y a guère de possibilité d'utiliser directement le multicore dans mon code, mais IIS s'adapte déjà bien à plusieurs cœurs/unités centrales en générant plusieurs threads/processus de travail en cas de charge.