concernant la programmation en parrallèle, effectivement, il ya comme un problème. Si le matériel est disponible pour effectuer des traitements en parralèle, nous n’avons pas de framework de développement (sauf celui cité qui s’intégrera dans le studio dot net) . Par ailleurs, comme le dit l’article, les techniques de développement ne sont pas encore très répandues parmi les développeurs en place dans les entreprises.
Pour ma part, je suis développeur dans une grosse banque. Mon job consiste à maintenir et alimenter les entrepôts de données. Dans le cadre de mon travail, j’essaie de voir ou on pourrait bien mettre du traitement parralèle, mais honnêtement, je ne vois pas trop où. (mais il est fort possible qu’il me manque tout bêtement le niveau conceptuel nécessaire). Nos traitements sont massivement séquentiels pour la bonne raison, que le traitement N+1 s’appuie sur le résultat du traitement N. Ce chaînage des traitements est la résultante de ce qu’est le fonctionnel.
Aussi, je me pose la question de savoir, si le traitement massivement parrallèle est applicable à tous les domaines du traitement de l’information. (il y aurait donc un travail à faire sur la conceptualisation, le passage du fonctionnel à la logique de prog. parralèle, snas compter la formation idoine pour les développeurs en place - comme à l’époque on a pu le faire avec la méthode merise appliquée aux bases de données )
Par ailleurs, concernant le processeurs à 1000 coeurs, est ce vraiement réalisable ?
Je prends l’exemple du threading en programmation java (ce qui est le début du traitement de données en parrallèle). Au dela d’un certain nombre de threads/processus lancés, la courbe de performance s’aplatit, car finalement le système passe plus de temps à gérer les accès en concurrence de tous les processus, voire à lancer et éteindre les différents processus que d’effectuer le travail en lui même (je sais c’est un résumé un peu grossier mais bon). Dans le cadre d’un processeur à 1000 coeurs, combien de coeurs seront uniquement dédiés à la gestion de l’ensemble ?
Comme dit dans un autre commentaire, l’optimisation des ressources existantes est sans doute plus intéressante. Le grid computing pourrait même sauver la planète (soyons visionnaire )) . prenez une tour à la Défense. Environ 3000 personnes y travaillent. Ce qui signifie, 3000 pcs, et mettons 500 serveurs. la nuit, les serveurs tournent à plein régime pour effectuer les traitements de données (par exemple l’intégration des flux d’informations des filiales de toute la planète, ce qui peut représenter 10Go de données à ingurgiter par nuit), pendant ce temps là, les 3000pcs, sont occupés à afficher l’écran de veille. en distribuant le calcul sur les 3000pcs, on pourrait faire baisser la pression sur les serveurs, rentabiliser au mieux les machines, et payer l’électricité du bazar pour autre chose, que les écrans de veilles (et au passage éviter de construire une centrale nucléaire pour alimenter tous les datas centers de paris par exemple).
01/09 16:52 - FuturHebdo
28/04/2058 : IA en marche 	 	 	 	 La société BNE, éternelle (...)
31/08 13:37 - kabreras
90% des bogues et des plantages viennet de conflits materiels / drivers, etc. Meme si les (...)
31/08 11:04 - Leekid
Bruxman dit : " Bref, traiter la langue naturelle ce n’est malheureusement pas (...)
30/08 19:32 - wiztricks
Les applications qui ont besoin de plus de puissance que celle offerte par un seul CPU (...)
29/08 02:08 - Sahtellil
28/08 20:18 - Siko
Ouais, je vois pas trop l’intérêt d’avoir une RAM commune puisque de toute façon, (...)
Agoravox utilise les technologies du logiciel libre : SPIP, Apache, Ubuntu, PHP, MySQL, CKEditor.
Site hébergé par la Fondation Agoravox
A propos / Contact / Mentions légales / Cookies et données personnelles / Charte de modération