URL: https://linuxfr.org/users/montaigne/journaux/les-processeurs-multicoeurs-et-lavenir-du-d%C3%A9veloppement Title: Les processeurs multicoeurs et l'avenir du développement Authors: Ontologia Date: 2007年06月28日T17:47:22+02:00 Tags: Score: 0 Un article intéressant dans un "Décision informatique" sur le "mur" qui s'approche de plus en plus dans l'industrie du développement de logiciels : Les processeurs deviennent massivement multicoeurs, sans augmentation significative de chacun des coeurs. Parallèlement, si les logiciels serveurs sont souvent conçu sur une architecture distribuées et/ou concurentes, les logiciels pour poste client sont rarement conçus pour des architectures parallèle, ce qui implique une sorte de stagnation des performances, si l'on se borne à conserver une approche monothread. Il y a donc des solutions à trouver rapidement, mais avec quel approche ? Adapter les frameWork (CLI chez krosoft, ou JVM chez SUN), afin de paralléliser au mieux ? On peut par exemple imaginer que chacun de ces éditeurs repensent leur librairies afin de les paralléliser au maximum : Le dessin d'une fenêtre peut ainsi être déporté sur un autre coeur (ce qui est surement déjà le cas). Plus généralement, on peut chercher à paralléliser au maximum l'utilisation de grosse fonction consommatrice de ressources de la librairie. Un autre voie, serait d'adapter les compilateurs afin qu'ils détectent du parallélisme implicite. C'est assez difficile vu la taille de langages comme Java ou C# (pour ne citer qu'eux), qui rend assez ardu l'analyse de code en vu d'une parallélisation de morceaux de programme, que le compilateur aurait détecté comme threadable. Ou bien, prendre le taureau par les cordes en programmant réellement multithread ? Le multithread pose de nombreux problèmes : très difficile à débugguer, il faut gérer ses verrous soit-même, etc... Bien que la programmation objet se démocratise, même chez des informaticiens peu formés, le commun du programmeur va t-il être capable de penser son code multi-thread et surtout de débugguer multithread ? Quid de ce que nous propose les labos ? On a déjà SCOOP(Simple Concurent Oriented Object Programming) chez Eiffel, mais bientôt COP (Concurent Oriented Programming) chez Lisaac (oui je prèche encore ma chapelle), dont le modèle simplifie (un peu comme SCOOP, mais en mieux) la concurrence en supprimant tout problème de verrou, d'accès concurent. Dans ces modèles, en gros, on détermine les objets parallélisable avec un mot clé (separate d'Eiffel), ou un style (un objet dont le nom est précédé d'un - sera automatiquement un thread autonome en Lisaac). En fonction du squelette objet de l'application, les traitements se parallélise et l'accès aux données se gère en fonction. Je ne me lance pas dans une explication, en quelques lignes c'est mission impossible. L'objectif sera à terme de rendre possible modèle défini ici [http://csl.ensm-douai.fr/MAAC/uploads/sonntagJMAC2006.pdf](http://csl.ensm-douai.fr/MAAC/uploads/sonntagJMAC2006.pdf) que j'ai justement conçu pour s'abstraire intégralement des problèmes de tuyauterie et disposer d'un modèle dans lequel le parallèlisme est natif dans le langage et sa logique. Un autre approche fait de plus en plus de bruit : la mémoire transactionelle. Dans ce système, la concurrence est gérée de la même manière que dans les bases de données transactionelles. Une très bonne explication est fournie ici : [http://fr.wikipedia.org/wiki/M%C3%A9moire_transactionnelle_l(...)](http://fr.wikipedia.org/wiki/M%C3%A9moire_transactionnelle_logicielle) , je ne vais pas la refaire :-) Je ne parle volontairement pas de méthodologie qui risquent d'être pourtant indispensable dans de nombreux projets, mais mon expérience d'ouvier-développeur me prouve (qu'en France au moins) on a plutôt tendance à l'oublier... Bref, personnellement, je pense que la programmation à thread classique va avoir du mal à s'imposer, car outre la nécessité de former les développeurs "de base", cela rend les logiciel difficilement débugable, oblige à mettre des _synchronise_ partout, et finalement oblige à une rigueur de conception et de développement qui n'existe à mon avis que dans les modèles conçus à la fac(où on a le temps).

AltStyle によって変換されたページ (->オリジナル) /