Les enjeux du parallélisme

S’il est un domaine où le logiciel accuse un retard par rapport au matériel, c’est bien le parallélisme. Alors que les machines multi-cœurs et multi-processeurs se généralisent, rares sont les applications capables d’exploiter cette montée en puissance. Q

Les enjeux du parallélisme : Lire la suite

Il est vrai qu'il est très étonnant de constater la quasi manque de prise en compte des processeurs multi-coeurs. Ces derniers ne sont pourtant pas nouveau et pourrai amener un réel plus aux utilisateurs.

Très bon sujet, moi qui suis totalement néophyte en programmation, quelque soit le langage, l'explication fut limpide et très instructive.

Pour revenir à Grand Central, je pense que dans un sens, c'est une très bonne initiative qui dans un premier temps accélérera les applications, mais qui d'un autre côté favorisera la faignantise des développeurs. Une application spécialement codée pour être multihread sera beaucoup plus rapide qu'une autre interprétée par ce genre de couche logiciel.

Cela me rappelle les prouesses des codeurs de démos en assembleurs sur des machines comme les Amiga. A cette époque, on savait ce que voulait dire "codes optimisés"... A méditer messieurs les programmeurs.

Ce point de l'article n'est pas vrai pour le Java. Le Java supporte nativement le multi-threading, et les JRE savent balancer les threads en multi-processeur depuis des années. Je le sais pour développer régulièrement des applis Java client et serveur qui utilisent le multi-coeur.

Ceci dit, les possibilités multi-thread de Java, même si elles sont "turin-complete", c'est à dire qu'elle autorisent théoriquement tout, restent frustres et difficiles à utiliser. Mais cela vient d'un problème d'abstraction du multi-tasking, qui est général à tous les langages, et pour lequel on n'est pas sûr qu'une solution simple et universelle naîtra un jour, plus que du Java. D'ailleurs, Java progresse, voir les nouvelles librairies multithread en Java 1.5.

En fait, il se peut tout simplement que le multi-thread soit condamné à rester une technologie complexe, quelle que soit le langage employé.

Là permettez moi de ne pas comprendre.. il aurait peut être fallu creuser un peu plus cette partie de l'article.
Peut-être que Edward A. Lee pense à la vectorialisation (SSEx, etc.) ?
Sinon ayant fait de l'imagerie, le découpage en thread donne la plupart du temps de meilleurs résultats (bench à l'appuis), c'est pourquoi je ne vois pas où vous voulez en venir quand vous parlez d'inefficacité.

C'est peut être un peu HS mais avec l'arrivée massive de processeurs multi-cores et peu d'applications le gérant correctement, ça ne fait pas déjà plusieurs années qu'on avait entendu parler d'une virtualisation de tous les coeurs physiques comme un seul processeur logique?
Une inversion du fonctionnement de l'hyperthreading en d'autres termes. Quand on voit qu'il y a quelques mois les pc portables haut de gamme (c'est un exemple) proposaient des dual core @ 2.4Ghz et qu'aujourd'hui on a des quad core @ 2Ghz, je reste un peu sceptique sur l'intéret.
En pratique, en tant qu'ancien joueur de WoW j'ai toujours maudit l'utilisation que d'un seul des coeurs de mon cpu pour ce jeu (et sûrement beaucoup d'autres) qui m'obligeait à me brûler les genoux en mettant la fréquence au maximum plutôt que de faire le même boulot à une fréquence moindre mais en répartissant la charge sur tous les coeurs dispo...

Ma petite expérience de programmateur amateur en Delphi.

Il y a quelques années, j'avais développé une petite application de rendu de carte, un peu dans le style Google Maps mais en local. La carte aux différentes échelles est découpée en tuiles de quelques centaines de pixels de côté.

1ère version (programmation classique): quand on navigue, ça lit le fichier de la tuile sur DD ou CD, ça le décompresse, ça le stocke en mémoire vive et ça le dessine à l'écran. Le problème, c'est qu'il y a blocage de l'application pendant les étapes de lecture et de décompression (sur en lecture sur CD).

2ème version (multithread): quand on navigue, le thread principal de l'application lance un thread de lecture/décodage par tuile et continue sa vie de son côté. Quand thread de lecture a fini son boulot, il envoie un message au thread principal pour que celui refasse le dessin de carte avec les données maintenant en mémoire. Le problème, c'est qu'on se retrouve par moment avec des dizaines de threads qui bouffent toutes les ressources du CPU et de la mémoire vive. En plus, il faut gérer l'accès au DD ou au CD et ne permettre l'accès qu'à un seul thread à la fois sous peine d'embouteillage. Donc, solution globalement pas satisfaisante.

3ème version (multithread avec une file d'attente): quand on navigue, le thread principal de l'application remplit une file d'attente de tuile à décoder et démarre un seul thread de décodage. Le thread de décodage exécute les travaux de la file d'attente les uns après les autres. À chaque fois qu'il a décodé une tuile, il envoie un message au thread principal pour redessiner la carte. Quand il a achevé la file d'attente, il se détruit. C'est pas mal mais ça fait redessiner la carte un peu trop souvent alors j'ai mis que le thread de décodage ne renvoie un message au thread principal qu'une fois par seconde. C'est la version actuelle. Elle est bien fluide même s'il reste quelques bugs, du style l'affichage n'est pas complété après le décodage de la dernière tuile. J'ai déjà pas mal souffert pour la mettre en oeuvre alors même qu'elle ne présente pas trop de problèmes de concurrence en thread juste qu'il ne faut pas lire et écrire en même dans la file d'attente.

4ème version (plusieurs threads sur la file d'attente): dans l'hypothèse où la décompression sur le CPU serait l'étape limitante, on voit qu'avec la solution précédente, un seul core est vraiment chargé, un second core assurant les gestions des opérations courantes comme l'affichage. La solution consiste à lancer plusieurs threads (>=nombre de core) qui travaillent en parallèle sur la liste d'attente. Les problèmes de concurrence entre threads font leur retour. J'y pense pour un de mes logiciels de traitement d'image par lot... puis j'oublie, vue comme j’ai eu du mal avec la version 3.

laugmentation des cores est un sinistre erreur
le temps passé par des milliers de personne à s'adapter à coder sur des multiprocesseurs incompétants est inproductif, ce qui est productif c'est qu'intel arrive a faire des processeurs plus puissants avec de nouveaux matériaux pour augmenter bien plus les fréquences, et garder 2 ou 4 coeurs pour le multi-application simplement, alors stop les vieux processeurs bidons de 2 Ghz qu'on se tape depuis 10 ans. INTEL AU BOULOT ON TE PAYE BIEN ASSEZ ALORS ARETE DE NOUS PONDRE DE LA DAUBE

certains ici semblent confondre parallélisation et multithreading. la programmation d'une machine multicoeur (par ex les cpu) est relativement aisée, c'est le multithreading. en revanche, la véritable paralélisation qui est nécessaire pour tirer partie des clusters ou des gpgpu est beaucoup compliquée, et c'est elle qui requiert des spécialistes. c'est véritablement une nouvelle approche de la programmation, l'évolution est encore plus grande que lors du passage de programmes linéaires aux programmes orientés objets.

pour info, dans un programme monothread, il est déjà très facile de tirer partie du multi-coeur: il suffit de réorganiser ses instructions (facile en assembleur) d'un pour que l'instruction 2 ne soit pas dépendante de l'instruction 1. ça devient très facile en x86 64bits grâce à l'augmentation du nombre de registres.
de toute façon, même si on se focalise là dessus en ce moment, tout n'est pas parallélisable. un peu comme l'intérêt du 64bits, qui, finalement, ne devient indispensable qu'a cause d'une bête limitation de mémoire... réservé grosso-modo aux calculs intensifs appliqués de manière identique sur un grand nombre de données, dès que l'ont fait intervenir une entrée utilisateur, la parallélisation devient inutile. vous voulez paraléliser notepad ou firefox, vous? n'oublions pas que la plupart du temps nos cpu ainsi que nos gpu se tournent les pouces, et c'est plutot heureux, car sinon la facture énergétique s'envolerait litéralement!
les différents fabricants de cpu comme intel et amd ne sont d'ailleurs pas avars en infos divers et manuels du programmeur disponibles gratuitement en téléchargement. mais là, on commence également a entrer dans le domaine de l'optimisation.

Bon article.

Mais bon, il aurait été intéressant de creuser plus la raison qui fait que le parallélisme (quelque soit la méthode : multithread ou multiprocess) est peu répandu.

Le contexte existe depuis plusieurs années mais les logiciels ne suivent pas. Ce n'est pas la peine de se gargariser avec les outils ... la gestion de plusieurs flux de traitements parallélisés demande un savoir-faire d'analyse tout simplement.

Le parallélisme se crée au moment de l'analyse. C'est tout un savoir-faire qui doit s'apprendre et s'enrichir par l'expérience.

Donc, les outils perlinpinpin-pouf-pouf-magique-clic-clic-ça-marche ne sont que des pièges-à-con histoire de faire cracher au bassinet toujours les mêmes pigeons qui croiront être hype avec le dernier outil très cher.

Bref, tout ceci me fait penser à une phrase que je sors à mes clients régulièrement (des bons gros méthodistes) : on peut poser dans un document des connaissances, mais pas un savoir-faire.

Voir un article qui dit que Java ne gère pas le MT nativement (en le comparant au C++) me fait doucement rire sur le niveau de l'article (et pas que moi apparemment)...
Pour le reste, Solendi +1 !

comme le dit nystep, le parallélisme a ses limites...
j'ai pas mal bossé à une époque sur le problème de la distribution d'algorithmes sur plusieurs machines et c'est un boulot à part entière.
il faut souvent repenser complètement l'organisation des données et des calculs effectués pour utiliser au mieux la puissance disponible.
en outre, il ne faut pas oublier que la communication entre chaque module de calcul n'est pas forcément gratuite en temps ce qui fait qu'à un certain point, ajouter des cores et découper plus finement fait perdre en performances.

un exemple tout bête est la décompression de fichiers: selon la méthode utilisée, il faut souvent avoir décompresser jusqu'au byte n pour pouvoir interpréter et décompresser le byte n+1. bien sûr on peut utiliser plusieurs threads pour assurer les I/O et "buffer"iser tout ça pour que le thread de décompression tourne à fond, mais le gain reste modeste.

la multiplication des cores c'est surtout - pour un usage grand publique - un argument marketing pour continuer à toujours vendre plus puissant alors que l'ère où les MHz s'envolaient continuellement est bien révolue. ça fait des années qu'on stagne autours des 3GHz et il semble qu'il y a la un mur qu'intel et consors n'ont pas réussis à franchir.

quand à la remarque "bientot un super ordinateur dans chaque PC", c'est déjà le cas depuis des lustres que les P3-P4 ont dépassés ce que savaient faire les CRAY d'il y a pas si longtemps que ça.

On voit s'accumuler des news annonçant des fermes de CPUs toujours plus puissantes, mais cela ne relève plus de l'utilisation d'une architecture ultime utilisant des optimisations poussées et tournant dans l'azote liquide mais de la multiplication du nombre de processeurs ordinaires.

Cela est certainement utile pour certains (de nature intrinsèquement parallèle) calculs à usage scientifique mais pas pour taper ce texte