- Preview du Centrino 4 (Santa Rosa)
- Tous les détails sur les Phenom/K10 d'AMD
- AMD présente son Turion X2 65 nm
- Intel économise parce que tout va bien
- Sun : le processeur Rock fonctionne
- IBM vide ses puces pour les faire tourner plus vite
- CPU-Z arrive en version 1.40
- Sun : le Niagara 2 est ''taped out''
- Deneb, Propus, Regor : AMD lit l'avenir dans les étoiles
- AMD : bye bye A64 X2 4000 , bonjour BE-2350
La semaine dernière fut particulière, car nous avons vécu au rythme du Computex. Ce salon fut cette année un bon cru, riche en annonces. Après quelques jours, il est intéressant de revenir sur celles-ci et de discerner les grandes tendances de l'industrie
Lire la suite
Source: EETimes – Mots-clés : microsoft, multithread, parallelisme
Catégories : Autres, Processeur
Le père de Microsoft a tenu un discours lors du sommet MVP (Most Valued Professionals) organisé par la compagnie afin de promouvoir la programmation multithread. C’est devant 2 000 personnes que Bill Gates a commencé par dire que les opportunités en matière de programmation étaient extraordinaires. Il a souligné les améliorations matérielles et l’augmentation du nombre de transistors. Il a aussi insisté sur le phénomène Internet.
Il s’est néanmoins attardé sur le fait que les processeurs ne montent plus en fréquence, mais voient leur nombre de core grimper. Il y voit donc un challenge alors que selon lui d’ici cinq ans, les ordinateurs de bureau de base, qui ont aujourd’hui deux cœurs, en auront 16 à 32. Il reconnaît que le parallélisme en programmation pose de nombreux challenges, mais Bill Gates prêche pour la résolution de ces problèmes. Il demande le développement de solution tirant parti de cette nouvelle puissance. Reste maintenant à voir ce que la firme fera avec ses produits phares tels que Windows et Office. Nous savons que Microsoft travaille déjà avec Intel pour faciliter la programmation en multithread avec ses outils de programmations.
-
Actualité précédente
Partenaire : Optimiser MSN -
Actualité suivante
Ca y est ! Neuf Cegetel a racheté...
Ecrire des applications bien "multi-threader" c'est pas evident, ya pas mal de pieges a eviter.
Il a pas tout a fait tort...
Ecrire des applications bien "multi-threader" c'est pas evident, ya pas mal de pieges a eviter.
Les pièges ne sont pas les seuls problèmes (avec de l'expérience, ça va encore).
C'est surtout trouver des moyens de décomposer des méthodes très "atomiques" dans les logiciels en plusieurs méthodes s'executant dans des threads séparés.
La on a plusieurs cas de figure:
1) On a plusieurs choses à faire, relativement indépendante les unes des autres (dans un jeu par exemple, calculer le rendu d'un object, mixer des sons, charger une partie d'un level depuis le disque dur): Dans ce cas, il est conceptuellement assez simple de threader l'application (même si la réalité montre que cela amène tout de même pas mal de complications)/
2) On a plusieurs choses à faire, mais il y a une étroite relation entre chacune d'elle: La, ça devient plus difficile, car les résultats d'un travail peuvent dépendre du résultat d'un autre. Un thread est donc obligé d'attrendre que l'autre est fini. Dans ce cas de figure, souvent, on ne gagne pas autant qu'on l'espérait. Pire, si tout ce mic mac est très complexe, on risque même de rendre le soft encore plus lent que sa version mono threadée.
3) On a une seule chose à faire et la, comment trouver un moyen ? (si tu dois porter un carton d'un point A à un point B, ça ne sert à rien d'être 3 ou 4 pour porter ce carton; tu n'iras pas plus vite). Pour certains choses, un bon mathématicien trouvera des solutions. Pour d'autres, il n'y en a pas vraiment...
Bref, c'est un vaste problème; les multi-core peuvent permettre d'obtenir des gains énormes dans bien des cas, mais ce n'est pas magique quand même...
Et ce qui est sur, c'est que les environment de développement doivent fournir plus d'outils pour faciliter la mise en oeuvre de solutions multi threadées.
mon Apache2 utilise quand même 252 threads à peine lancé !
ça c'est l'exemple typique d'application qui bénéficie pleinement du multi-thread: Pleins de travaux indépendant à faire... Mise en oeuvre qui "coule de source".
mon Apache2 utilise quand même 252 threads à peine lancé !
Oui mais si un seul d'entre eux a besoin de 99% des ressources système, le multicore n'apportera rien.
Le multithread est nécéssaire mais loin d'être suffisant pour profiter de la puissance des multicore.
Et ce qui est sur, c'est que les environment de développement doivent fournir plus d'outils pour faciliter la mise en oeuvre de solutions multi threadées.
Sur ce point je suis pas tellement d'accord avec toi. Le gros probleme selon moi c'est plutôt au niveau de la formation, de mon point de vue elle est bien trop insuffisante en ce qui concerne le multi-threading. Un dev aura beau avoir tout les outils pour développer une application multi thread, il aura bien plus de mal a faire du bon travail s'il n'a pas ete familiariser au concept.
Sur ce point je suis pas tellement d'accord avec toi. Le gros probleme selon moi c'est plutôt au niveau de la formation, de mon point de vue elle est bien trop insuffisante en ce qui concerne le multi-threading. Un dev aura beau avoir tout les outils pour développer une application multi thread, il aura bien plus de mal a faire du bon travail s'il n'a pas ete familiariser au concept.
C'est un commentaire qui me semble pertinent surtout lorsque je vois les efforts fait par Intel pour former et convertir les programmeurs, je me dis qu'il doit y avoir de gros gros besoins et donc de grosses lacunes à un moment donné ou en tout cas un manque de familiarisation avec le concept
Les articles sont très intéressants.
Reste les compilateurs conçus pour faire des application de ce type, mais là encore, ce n'est pas une chose simple.
Ca m'étonnerait que cette voie dure aussi longtemps que la voie de la montée en fréquence.
Sur ce point je suis pas tellement d'accord avec toi. Le gros probleme selon moi c'est plutôt au niveau de la formation, de mon point de vue elle est bien trop insuffisante en ce qui concerne le multi-threading. Un dev aura beau avoir tout les outils pour développer une application multi thread, il aura bien plus de mal a faire du bon travail s'il n'a pas ete familiariser au concept.
Oui et non.
Oui, car il est vrai que beaucoup de dev ne maitrisent pas le multi threading et les contraintes que cela impose. Dans ce cas, très honnêtement, c'est un gros manque d'expérience. Un dev digne de ce nom, qui a 10ans d'expérience et qui ne maitrise pas les concepts fondamentaux et les problématiques d'une programmation multi threadée (gestion des accès aux resources partagées, race condition etc.), y'a un problème...
Non, car ce dont je parlais, c'est un niveau d'abstraction supérieur à celui proposé aujourd'hui. Que tu prennes des bonnes vieille lib en C++ ou des trucs plus moderne en C# ou Java, l'abstraction se situe toujours au niveau du thread: T'as un object thread, ou un truc qui l'encapsule un minimum. Pour certains problèmes courant, je suis sur qu'on pourrait avoir des libs qui s'occupent elles même de créer des threads pour faire tel ou tel boulot, quand cela est nécessaire et possible, sans que le programmeur s'en préoccupe: Gros gain de temps.
Car ne l'oublions pas, un développement efficace, ce n'est pas se faire plaisir en maitrisant des trucs de bas niveau (Même si c'est toujours valorisant et/ou amusant). Non. C'est en faire le plus en un minimum de temps. Donc, souvent, il faut pouvoir augmenter le niveau d'abstraction quand cela est possible pour se concentrer sur des choses offrant une réèlle valeur ajouté au soft que l'on développe.
Donc, non, actuellement, il n'y a pas assez de choses offertes aux dev à ce niveau.
Mais concrètement, tu as une idée de ce qu'il faudrait?
Des libraries de fonctions sachant nativement créer des threads quand cela est possible. Prenons un exemple simple:
Tu as un gros (énorme) document Word ou PDF, peu importe et tu veux effectuer une recherche dessus. Actuellement, ta fonction de recherche est monothreadée: Le même thread va parcourir tout le document à la recherche du mot clef que tu as spécifié. Si le mot clef est à la fin, dommage, le résultat peu mettre plusieurs seconde à arriver (le document est très très très gros
Toi programmeur, comment tu pourrais optimiser ça ? Sachant que ton document est en mémoire, tu pourrais imaginer plusieurs thread, chacun s'occupant de rechercher dans une partie spécifique du document. Par exemple le thread 1, recherche dans la 1ère moitier du document pendant que le thread 2 s'occupe de la 2ème moitié. La déjà, si le mot recherché est à la fin, tu vas quasi 2 fois plus vite qu'avec la méthode 1; le thread 2 trouvant plus rapidement le mot recherché, vu qu'il a démarré du milieu du document.
Putain oui, mais faut l'écrire le bordel, même si cela n'est pas très complexe.
Si tu avais un object spécialisé dans la recherche de mot clef dans un document, tu lui passe le document, le mot clef a rechercher, et de lui même, il créé les threads (suivant la config courante de la machine; pas la peine de créer 4 thread sur un mono-core, ça ira pas plus vite). Plus besoin de t'occuper du boulot.
En faisant bien le boulot, tu peux même imaginer rendre cet object de recherche générique (customisable via polymorphisme ou encapsulation d'object métier à l'interface défini), pour qu'il puisse rechercher le plus rapidement possible n'importe quoi dans toute liste d'objects en mémoire (un document n'étant qu'une liste d'objects décrivant son contenu).
Je suis sur qu'il y a moyen de trouver des milliers d'exemple de ce style (certainement plus pertinents). Ou le besoin est récurrent en développement, mais ou la librairie qui traite ce besoin n'existe pas encore.
Des libraries de fonctions sachant nativement créer des threads quand cela est possible. Prenons un exemple simple:
).
Tu as un gros (énorme) document Word ou PDF, peu importe et tu veux effectuer une recherche dessus. Actuellement, ta fonction de recherche est monothreadée: Le même thread va parcourir tout le document à la recherche du mot clef que tu as spécifié. Si le mot clef est à la fin, dommage, le résultat peu mettre plusieurs seconde à arriver (le document est très très très gros
Toi programmeur, comment tu pourrais optimiser ça ? Sachant que ton document est en mémoire, tu pourrais imaginer plusieurs thread, chacun s'occupant de rechercher dans une partie spécifique du document. Par exemple le thread 1, recherche dans la 1ère moitier du document pendant que le thread 2 s'occupe de la 2ème moitié. La déjà, si le mot recherché est à la fin, tu vas quasi 2 fois plus vite qu'avec la méthode 1; le thread 2 trouvant plus rapidement le mot recherché, vu qu'il a démarré du milieu du document.
Putain oui, mais faut l'écrire le bordel, même si cela n'est pas très complexe.
Si tu avais un object spécialisé dans la recherche de mot clef dans un document, tu lui passe le document, le mot clef a rechercher, et de lui même, il créé les threads (suivant la config courante de la machine; pas la peine de créer 4 thread sur un mono-core, ça ira pas plus vite). Plus besoin de t'occuper du boulot.
Je suis sur qu'il y a moyen de trouver des milliers d'exemple de ce style (certainement plus pertinents).
Question con mais c'est pas le but des pragmas en OpenMP ?
Question con mais c'est pas le but des pragmas en OpenMP ?
Les pragma servent à définir la manière dont tes zones de code vont être gérée par un thread. ça reste à très bas niveau. Donc, interessant, mais pas productif à mon sens.
Faut réfléchir à comment les utiliser. Donc, passer du temps à gérer l'aspect threading au lieu de passer du temps à gérer la finalité de ce que tu veux faire.
Ou disons, que ça sert à écrire les librairies/framework que j'aimerai voir apparaitre un peu plus !
Avec les dernières versions des frameworks .NET et Java, y'a pas des manières plus intuitives de faire des threads ?
En .NET (En Java pas vu, mais doit surement y avoir mais j'ai pas beaucoup d'expériences en Java) y'a une classe BackgroundWorker qui permet de balancer une opération threadée avec un minimum d'effort: tu passes la méthode à executer, la méthode déléguée appellée quand le thread est fini (et même optionnelement quand le thread signale une progression) et c'est tout. Pratique, mais comme je l'ai dit avant, si cela permet de démarrer un thread très rapidement sans taper beaucoup de code, d'une part ce n'est pas adapté à certaines utilisations et c'est toujours toi qui est obligé de décider quand et comment tu va gérer tes threads.
Peut-être que .NET 4.0 amènera une API pour threader facilement et intelligemment !
Peut-être que .NET 4.0 amènera une API pour threader facilement et intelligemment !
Peut être. Mais, je pense que ce genre d'API se retrouvera plutôt sous la forme de services spécifiques (genre un service permettant de développer rapidement un serveur d'application du style IIS, Apache etc... ou un autre permettant de traiter plus facilement le threading dans les jeux etc...).
Il ne peut y avoir de choses miraculeuses non plus. Genre, j'écris une méthode et paf grace à une autre, ma fonction s'exécute sur plusieurs threads; outre le fait que cela n'a aucun sens dans de nombreux cas, ce n'est surtout pas vraiment réalisable: le besoin de threader ne s'exprime et ne se résout que par rapport à un problème donné. Difficile de faire du "générique" dans ce cas là (sinon, on aurait déjà ce genre de choses).
Mais je suis sur que la démocratisation massive actuellement d'ordinateurs perso multi-core, va créer le besoin (parlons peut être plutôt d'opportunité) de ce genre de services; et on aura surement la chance de voir fleurir ce genre de choses dans les environment de devs avenirs.
le multithreading ne va pas trop se développer tant que l'on aura pas éliminé les problèmes des locks.
Ne pas oublier quand même que le multi-threading n'a pas attendu les procs multi-core, ni même les ordinateurs multi-processeurs.
Il est souvent intéressant d'avoir un thread ne serait-ce quand tu fais de l'UI: Dès qu'une opération est un peu longue, tu la lances dans un nouveau thread pour éviter de blocker l'interface utilisateur. Problème fréquent.
Idem pour toutes les applies serveurs qui doivent gérer des requêtes de manière indépendante.
Le multi-threading est aujourd'hui (et depuis longtemps) très développé dans divers domaines. Il doit maintenant se développer dans d'autre pour profiter de l'augmentation des unités de calculs de ordis actuels.
Les problèmes de locks ne sont pas les seuls problèmes (même si en effet, c'est un frein, car cela peu devenir très complexe dans certains cas); il y a aussi la manière de penser qui doit radicalement changer. C'est certainement le plus complexe.
Mais je suis sur que la démocratisation massive actuellement d'ordinateurs perso multi-core, va créer le besoin (parlons peut être plutôt d'opportunité) de ce genre de services; et on aura surement la chance de voir fleurir ce genre de choses dans les environment de devs avenirs.
pour le reste je suis d'accords, sauf sur le fait que changer de manière de penser soit le problème principal, quand je prend un dev au hasard et je lui demande pourquoi il ne fait pas de parallélisation, la plupart des réponses c'est ''ça en vaut pas la peine'', et ''ça crée des bug chiants à résoudre'' et le dernier ressort pathfinder ...
changer de manière de penser ça viendra tout seul, en attendant, dans certains domaines peu de gens osent paralléliser ...
je répondais juste à
our le reste je suis d'accords, sauf sur le fait que changer de manière de penser soit le problème principal, quand je prend un dev au hasard et je lui demande pourquoi il ne fait pas de parallélisation, la plupart des réponses c'est ''ça en vaut pas la peine'', et ''ça crée des bug chiants à résoudre'' et le dernier ressort pathfinder ...
changer de manière de penser ça viendra tout seul, en attendant, dans certains domaines peu de gens osent paralléliser ...
C'est clair; surtout qu'on peut très bien d'obtenir des résultats plus lent une fois parallélisé... (genre paralléliser des tâches qui demandent un gros accès disque sur... un seul disque... déjà vu la connerie...)
à votre avis comment fonctionne les data centers de 8000 cpus ?? et là on parle de limitation à partir de 8 cores ??? erk
ça n'a rien à voir.
Dans un Data Center tu héberges une ou plusieurs applications (identiques ou distinctes) par machine. Rien à voir avec le fait qu'un application puisse se décomposer en milliers de threads. Et si certaines applications (genre scientifiques, comme folding@home) se prêtent très bien à une utilisation multi-threadée (enfin dans le cas de folding@home c'est même du multi-processus, donc plusieurs instances de la même applications qui tournent sur différentes machines), car on peut facilement décomposer les calculs en plusieurs unités distincts.
Va décomposer le workflow nécessaire à l'affichage d'une image dans un jeu dans 8000 threads, tu m'en diras des nouvelles !
Même si on peut très bien imaginer au final, un univers virtuel complètement fou ou chaque calcul nécessaire à la gestion d'une entité vivante est faite dans un thread; m'enfin y'aura toujours le besoin à un moment donné de recupérer le résultat de chaque thread pour "l'assembler" et obtenir le résultat final (une image à l'écran) et pouvoir ensuite redonner de quoi "manger" à tous ces threads en fonction des précédents résultats (donc beaucoup de synchro nécessaires, donc beaucoup de problèmes en perspective: pas seulement de bugs potentiels mais carrement des problèmes d'optimisation dans le sens où d'intérêt même de tout threader peut être remis en cause par des gains finaux peu concluants.