Programmation : toujours le débat du multicore

Multi-cores, les développeurs grommellent ...

Herb Sutter, responsable du développement logiciel chez Microsoft annonce que les développeurs du monde entier doivent se concerter avec l'avènement du dual-core et du multi-core dans les processeurs grand public.

Les développeurs de logiciels sont d'accord sur le fait que les fabricants de processeurs devaient se tourner rapidement vers les solutions du multi-core pour régler les problèmes de chaleur et d'augmentation de fréquence sur leurs carrés de silicium. Mais ils regrettent que ces fabricants n'aient pas vraiment pris en compte les difficultés que cela va poser aux développeurs.

Pendant de nombreuses années, les développeurs ont pu exploiter les performances apportées par les derniers processeurs, en modifiant peu ou pas leurs programmes. Mais avec l'arrivée du multi-core, les choses se compliquent particulièrement. Les développeurs doivent accorder beaucoup d'intérêt à la simultanéité - ce qui consiste à « casser » plusieurs parties de leurs programmes afin qu'ils puissent être exécutées ensemble puis rassemblées. Cette optique permet effectivement, de tirer profit du multi-core, mais rend la programmation beaucoup plus complexe.

Les développeurs qui programment depuis longtemps des applications pour les serveurs sont toutefois plus « habitués » à ce genre d'optique. Les serveurs étant généralement composés de systèmes multi-processeurs ou multi-cores.

Tout est question de « simultanéité » ?

Mais pour les développeurs d'applications grand public la tâche sera bien plus ardue. Herb Sutter compare d'ailleurs l'arrivée de la « simultanéité » à celle de l'arrivée de la programmation orientée objets. Cela devrait ainsi ajouter de nouvelles complexités aux développeurs qui devront notamment revoir leurs façons de programmer et d'imaginer leurs codes. Gabe Newell, le créateur du jeu Half-Life 2 s'est d'ailleurs déjà exprimé au sujet du multi-core et il ne semblait pas très enthousiaste à ce sujet (voir cette brève).

Selon Herb Sutter, Microsoft travaillerait sur un projet nommé « Concur » pour aider et simplifier la tâche des développeurs avec l'arrivée du multi-core. Mais il précise, qu'à l'avenir, les fabricants de processeurs devront consulter davantage les développeurs au sujet de leurs choix technologiques : « les fabricants doivent se concentrer sur la "programmabilité" d'abord et ensuite seulement sur la vitesse... ». Il semblerait donc, que les programmes optimisés multi-core ne verront certaiment pas le jour demain, les processeurs multi-core resteront une priorité pour les utilisateurs qui restent attachés à une utilisation très « multitâches » de leur machine.

Lire cette brève sur le site

Ben oui. multi process, multi thread à tous les étages et certains diagrammes d'uml qui vont passer à la trappe... Quels sucesseur? réseaux de petri pour modéliser les (a)synchronisations?

De même que la programmation objet ne s'est vraiment imposée qu'avec l'apparition de langages pur-objet, je pense que ce type de programmation ne connaitra son essor que lorsque qu'un langage approprié verra le jour.
Après la gestion de mémoire automatique, à quand un langage capable de diviser automatiquement les taches en threads ? Je pense par ailleurs que c'est le prolongement logique de la programmation objet.

en gros, ils ont pas envi de se casser le cul, les pauvres...

Mais :lol:

ils sont plusieurs dixaine à travailler sur un logiciel...


:pfff: desolant....

Pour ceux qui veulent faire plusieurs choses à la fois c'est quand même très intéressant. Ceci dit, au niveau des développeurs, l'utilisation des threads est quand même quelque chose de bien ancré dans les moeurs. Ce n'est pas du tout comme un nouveau langage, c'est juste une optimisation d'une fonctionnalité présente sur tous les systèmes d'exploitation.

Une vraie innovation serait un processeur capable de gérer *aussi* des objets nativement, et muni d'un garbage collector efficace. Les pointeurs, les allocations mémoire et les interuptions, ça fait 40 ans que ça dure et bien peu de logiciels sont encore développés en assembleur...

En même temps la plupart des utilisateurs font du multitâches sur leur poste ... Avec également la multiplication des tâches de fonds (antivirus, client mail ...).

Ca n'empêche que le multi-core le 64bit & co ca sera vraiment puissant qd les applications seront optimisé et ca c'est vrai que les consommateurs ont largement tendance à l'oublier.

GogoGadget: Mouais . Le multithread est déjà utilisé, mais il n'a pas d'intérêt réel pour de nombreuses utilisation et en mono cpu.

Et précisément quand on utilise le multithread dans un environement monocpu c'est pour éviter de se prendre la tête. Ex. programme de lecture multi média : un thread pour la video un pour l'audio un pour les sous-titres, et rarement un seul thread qui lit et interprète le son et l'image ... (mplayer est le seul que je connaisse à utiliser cette seconde méthode)

Salut

Je me demandai si un programme est ecrit pour un proc dual-core. Est ce qu'il va aussi fonctionner pour un simple core?

Oui.
C'est le problème du système d'exploitation de répartir les resssources.

Stic > oui, ça il n'y a pas de pb

Il y a un truc que je ne comprends pas, si un programme est déjà multithreadé, il est déjà adapté au multicore, non (en exécutant un thread différent sur chaque core) ?
ou alors il faut changer autre chose dans la programmation ?

Vincent a écrit:
Multi-cores, les développeurs grommellent ...

[...]

Il semblerait donc, que les programmes optimisés multi-core ne verront certaiment pas le jour demain, les processeurs multi-core resteront une priorité pour les utilisateurs qui restent attachés à une utilisation très « multitâches » de leur machine.

Lire cette brève sur le site

Euh ... je ne m'y connais pas trop dans le domaine, mais ne fait-on pas plus ou moins tout le temps du multitaches quand on est sous windows ? Il y a toujours plusieurs petites applis qui tournent en arriere plan non ? Du coup, lorsqu'on lance un jeu, meme si celui-ci n'est pas développé pour du multi-core, s'il a besoin de beaucoup de ressources, il devrait quand meme y avoir moyen de lui dédier un core à lui tout seul et faire tourner toutes les autres petites applis sur le second core. Ca gagnerait dejà un peu en performance non ? (plus de passage d'une tache a une autre pour ce coeur).

Je veux bien etre éclairé sur ce principe. :)

Corwin

d9pouces: oui en effet.
Corwin4Amber: en effet aussi, mais il y a moyen même pour un jeu de gagner encore plus en faisant tourner l'application sur 1 cpu à 100% et à 80% sur le second.

Mais de nombreux calculs qui sont fait de manière simple peuvent être parallélisées, et ne le sont pas forcément en mono cpu.

Par exemple (trivial)
la somme de 1 à n peut être en mono cpu
1+2+3 +... +n
Mais en dual core:
somme partielle = 1+2+3...+ n/2 sur chaque cpu
et
somme totale = somme partielle1 + somme partielle 2

(Là l'exemple est trivial et pas interressant puisque le résultat d'un tel calcul est connu d'avance avec une complexité O(1) (formule de somme des série))
La même chose peut être faite avec des calculs plus complexe où faire le calcul entier peut être divisé en plusieurs calculs partiel et faisables en parallèle.

Je ne sais pas si je suis clair?

v_atekor a écrit:
d9pouces: oui en effet.
Corwin4Amber: en effet aussi, mais il y a moyen même pour un jeu de gagner encore plus en faisant tourner l'application sur 1 cpu à 100% et à 80% sur le second.

Mais de nombreux calculs qui sont fait de manière simple peuvent être parallélisées, et ne le sont pas forcément en mono cpu.

Par exemple (trivial)
la somme de 1 à n peut être en mono cpu
1+2+3 +... +n
Mais en dual core:
somme partielle  = 1+2+3...+ n/2 sur un cpu chaque
et
somme totale = somme partielle1 + somme partielle 2

(Là l'exemple est trivial et pas interressant puisque le résultat d'un tel calcul est connu d'avance avec une complexité O(1) (formule de somme des série))
La même chose peut être faite avec des calculs plus complexe où faire le calcul entier peut être divisé en plusieurs calculs partiel et faisables en parallèle.

Je ne sais pas si je suis clair?

c'est quand même plus rapide de pondre directement n*(n+1)/2 ^^
ce qui se parallélise à peu près bien, c'est le calcul matriciel, heureusement d'ailleurs vu que c'est ce qu'il y a de plus utilisé dans les très gros calculs ^^

"en effet" > à propos des threads ? pourtant la majorité des programmes sont multithreadés, non ? donc ça ne devrait pas posé de problèmes pour le passage au multicore, alors ?

Corwin4Amber a écrit:
Euh ... je ne m'y connais pas trop dans le domaine, mais ne fait-on pas plus ou moins tout le temps du multitaches quand on est sous windows ? Il y a toujours plusieurs petites applis qui tournent en arriere plan non ? Du coup, lorsqu'on lance un jeu, meme si celui-ci n'est pas développé pour du multi-core, s'il a besoin de beaucoup de ressources, il devrait quand meme y avoir moyen de lui dédier un core à lui tout seul et faire tourner toutes les autres petites applis sur le second core. Ca gagnerait dejà un peu en performance non ? (plus de passage d'une tache a une autre pour ce coeur).

Je veux bien etre éclairé sur ce principe. :)

Corwin

Dans le gestionnaires des tâches, affichage, sélection des colonnes, tu peux cocher "nombre de threads".
Windows va automatiquement décidé quel(s) thread(s) doit être traité, et il réparti la charge selon les besoins. Les threads sont généralement en état de sommeil profond, et même lorsqu'ils sont actifs, c'est bien souvent qu'ils attendent une entrée/sortie (disque, réseau, clavier, ...) et pendant ce temps là l'OS passe à autre chose en attendant (au niveau CPU).

Le problème des threads, c'est la synchronisation. Aucune solution miracle existe, et le dead lock (blocage interthread, a attend b qui attend c qui attend a) est facile...

d9pouces : C'est ce que je dis à la fin, la formule est en O(1) ;) C'est pour l'exemple. Sur une fft c'est moins évident de voir l'avantage.
Non, la majorité des programmes sont mono threadés, ou alors c'est du multithread pour rendre les choses pratiques (ouvrir une boite de dialogue sans bloquer le reste), pas pour profiter de la puissance de calcul.
Aujourd'hui un logiciel qui affiche une image reste bloqué en attendant la fin de l'affichage. Ce pourrait être différent si l'affichage était réalisé par un thread indépendant... Gare aux dead locks quand même :ane:

Gaby44: Oui, mais tu ne profiteras pas de la puissance de calcul du second processeur avec une application (active) n'ayant qu'un seul thread.
Synchronisation -> doù l'intérêt de modèles par réseaux de Petri et l'abandon de certains diagrames uml. ;)

Du point de vue du développeur, c'est un boulot intéressant. Ils ont raison de dire que c'est la même révolution que le passage à l'objet. Ce sont surtout les éditeurs qui "font la gueule" parce qu'ils vont devoir payer tout ce petit monde.
ça va un peu plus loin que du simple "multihtreading": c'est du "parallélisme": c'est à dire faire tourner en gros un même algorithme sur plusieurs procs/core à la fois, avec les synchro qui vont bien, dans le but de répartir équitablement entre tous les procs: contrairement à un simple multithreading ou on ferait tourner le son sur un proc, la video sur un autre, et qui n'ocupperait un des 2 procs qu'à un faible pourcentage: dommage d'avoir un proc à 10% et l'autre à 100%, même si on y gagne.

Enfin, pour les langages de prog: les scientifique s'y sont déjà penchés pour les calcul: il y a eu des tentative de surcouche au dessu de Fortran. mais apparamment, c'est surtout le C, le Fortran, et peut-être l'ada qui sont utilisé, et ne sont donc pas dédiés.
:)
à la soupe..

v_atekor a écrit:
d9pouces : C'est ce que je dis à la fin, la formule est en O(1) ;) C'est pour l'exemple. Sur une fft c'est moins évident de voir l'avantage.
Non, la majorité des programmes sont mono threadés, ou alors c'est du multithread pour rendre les choses pratiques (ouvrir une boite de dialogue sans bloquer le reste), pas pour profiter de la puissance de calcul.
Aujourd'hui un logiciel qui affiche une image reste bloqué en attendant la fin de l'affichage. Ce pourrait être différent si l'affichage était réalisé par un thread indépendant... Gare aux dead locks quand même :ane:

ah ? je pensais que la plupart des progs étaient multithreadés, surtout que ça fait tellement longtemps que ça existe et qu'on sait que c'est l'avenir à court/moyen terme :/

deltree: Pour le langage, de simple bibliothèques font souvent l'affaire. Le hic est sur le modèle à utiliser : arriver à 'penser parallélisme' comme on 'pense objet'

Vincent a écrit:
Mais il précise, qu'à l'avenir, les fabricants de processeurs devront consulter davantage les développeurs au sujet de leurs choix technologiques  : « les fabricants doivent se concentrer sur la "programmabilité" d'abord et ensuite seulement sur la vitesse... ».

Ben tiens... Et les developpeurs vont peut etre venir apprendre à Intel et AMD comment on fait des transistors 10nm qui tourne à 100GHz avec 1 milliard de transistors et qui ne developpent que 1W ? Pour les programmeurs, suffit d'arreter de developper de nouveaux processeurs pendant 5 ans... Et peut etre qu'ils se bougeront un peu plus pour optimiser leur programme... Rien que là, y a de quoi gagner un facteur 10 en perf... :whistle: