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 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(...) , 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).
Journal Les processeurs multicoeurs et l'avenir du développement
28
juin
2007
# Les librairies ...
Posté par Anonyme . Évalué à 7.
- OpenGL: si je me trompe pas, OpenGL se comporte principalement comme un flux de données unidirectionnel, il est possible de faire exécuter du code de la librairie dans un thread a part pour redonner la main a l'application le plus tôt possible (Apple a fait une expérimentation concluante il me semble). Tout n'est sans doute pas parallélisable (tout les traitement ce qui ne retourne pas des résultat en gros).
- malloc : malloc n'est pas lent, mais je ne serais pas surpris qu'on puisse l'accélérer en préparant des bloc mémoire a l'avance dans un thread a part, pré alloués, donc.(cela se fait déjà pour les applications multithread pour éviter les lock lors du choix des blocs)
- Les libs graphiques : toutes ont des traitements un peu lourds (décodage d'image, rendu svg ou autre) qui pourraient être effectués dans un thread a part. Pour éviter le cout de création d'un nouveau thread, il faudrait plusieurs threads réutilisables dès le départ. Le souci c'est si les application ont besoin d'un résultat synchrone, il faudra prévoir des systèmes de lock casse tête.
- D'une manière générale tout ce qui peut être surveillé : faires des petites analyses statistiques sur l'application pour préparer un maximum les entrées sorties.
Le GROS problème c'est que beaucoup, beaucoup de code est du traitement de données brut : le résultat d'un appel doit souvent être synchrone par ce que les applications veulent utiliser le résultat dans la suite du chemin d'exécution. Sans oublier que dès qu'on charge un peut la bête tout se casse la figure, l'overhead des ce genre de systèmes étant rarement négligeable.
Il faut aussi noter que le résultat ne sera que du confort utilisateur, on ne peut pas améliorer les performances d'une application par ce biais, seulement rendre l'exécution plus rapide d'un point de vue utilisateur (en gros tout sera plus lourd, voire beaucoup plus lourd, mais perçu comme plus rapide).
[^] # Re: Les librairies ...
Posté par paul . Évalué à 2.
je ne suis pas sûr de comprendre ce que tu entends par on ne peut pas améliorer les performances d'une application par ce biais ?
Qu'est-ce que la performance ?
Le temps absolu d'exécution complète de la tâche ? Dans ce cas si tu parviens à paralléliser le traitement, le temps d'exécution sera divisé sur une machine multi-coeurs, donc on gagnera en performance.
Si la performance, c'est le nombre de cycles processeur qu'il a fallu en tout pour exécuter la tâche, dans ce cas en effet on ne gagne pas en performance. Mais qui se souci de ce critère ?
Ce qui compte le plus aujourd'hui, c'est :
- combien de temps faut-il pour effectuer mon opération ?
- combien d'énergie électrique ce traitement a-t-il exigé ?
Sur ces deux points, la parallélisation sur multi-coeurs à basse fréquence semble être une excellente solution. Le "hic", c'est ce qui est bien décrit dans le journal ci dessus.
[^] # Re: Les librairies ...
Posté par Anonyme . Évalué à 3.
C'est essentiel : Cela conditionne l'énergie consommée par ton système, et la réaction du système au fortes charge. (domage d'avoir un truc réactif en faible charge qui d'étouffe en forte charge).
C'est pour ca que "la performance de l'application" est importante : je suis d'accord en faible charge pas de souci, mais personnellement j'aime bien avoir du matériel a jour pour que le pics de charge passent aussi en douceur[1] ... or ici c'est clairement un problème : si toutes les applis ont un overhead supplémentaire il est clair que cela se sentira. Une 'application performante' s'en sort mieux que les autres dans ce cas de figure.
[1] : je ne veux pas que les fps de compiz baissent, que mon lecteur de musique coupe, que mes applications de répondent pas quand je suis en train d'ouvrir 10 onglets avec firefox, jouer avec le bureau 3D et en compilant mon noyau (-j2). Ce cas de figure est optimum avec les applications mono processus, mais que se passe t'il avec des librairies multi-thread ?
# D'façon...
Posté par Snarky . Évalué à 2.
http://www.techno-science.net/?onglet=news&news=4000
:)
# Multithread ?
Posté par Matthieu . Évalué à 6.
# En Lisaac
Posté par Mildred (site web personnel) . Évalué à 2.
Sinon, ça se passera comment, car un -devant le nom du prototype ca correspond à quoi. Ca va se passer comme ça ?
Section Header
- name := PROTOTYPE;
ou comme ça ?
Section Header
- name := - PROTOTYPE;
Car la première manière a déja une signification si je ne me trompe (prototype non clonable) alors que la seconde paraît bizarre.
En tout cas, j'aprécie beaucoup la programmation agents. Dans le cas d'un projet à l'IUT j'ai eu l'occasion de faire un mini-serveur/client en Java en utilisant au maximum cette notion. En gros j'avais pas mal de thread. Le seule problème que j'ai eu c'était pour implémenter la communication entre tous ces threads, justement pour avoir cette notion d'agents.
[^] # Re: En Lisaac
Posté par Ontologia (site web personnel) . Évalué à 1.
- devant le nom du prototype ne signifiera plus "non clonable", mais "exécution parallèle de ce prototype".
On ne pourra plus avoir de macro-objet en +
Si un objet '-' hérite d'un objet +, un clone de l'objet - provoque un nouveau thread avec une duplication automatique de son parent en +.
(Cela conserve la notion + chacun le sien, - partage)
si B hérite de A avec A et B en -, alors un clone de B crée un thread mais ne clone pas A, par contre si A est en +, ça clone A.
L'idée consiste ensuite à ne faire communiquer que les slots de type
- à l'intérieur de l'objet.
Dans le modèle qui est défini ici http://csl.ensm-douai.fr/MAAC/uploads/sonntagJMAC2006.pdf , tu as justement un modèle agent implémenté au sein du langage. Je voulais faire un petit jeu de sous marin en Java, et je m'étais un peu trop pris la tête, ce qui m'avait conduit à définir un cadre permettant de définir des systèmes multi-agents.
Non seulement, un agent peut appartenir à un système multi agent, mais il peut être lui même un système multi-agent, c'est à dire, qu'un groupe d'agent peut "être" cet agent. Cela permet d'intégrer la notion "académique" de système multi-agent qui est intrinsèquement récursive.
Mais cela permet en plus de dialoguer entre agent en définissant les conditions que doivent respecter tes agents pour recevoir le message.
Ca utilisera la réflexivité.
Reste à implémenter le SQL, et on aura un des meilleurs langage du monde ;-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.