Articles précédents : Articles
- [3] Solutions Linux 2007
- [53] Régulation du net : un projet de décret inquiétant
- [6] Aquitaine Libre : 1ère journée régionale du logiciel libre, de la musique libre et de l'informatique
- [18] Sortie de la version 2.0 du projet Armadeus
- [50] Linux en entreprise : deux nouveaux exemples de migration
- [3] Conférence le 22 février à Paris (CNAM & La Recherche)
- [15] OpenChange: Communiquez avec Exchange depuis Linux
- [7] Libre en fête autour du 21 mars 2007
- [9] Cassandra, le logiciel de visualisation scientifique 3D utilise VTK 5.
- [38] kqemu devient libre, qemu 0.9.0
Liens connexes
- La conférence ISSCC (377 hits)
- Le Power6 (1379 hits)
- Le Niagara 2 (1004 hits)
- Le Barcelona (1089 hits)
- Le PA6T (1071 hits)
- Le prototype Intel 80 coeurs (2205 hits)
Dépêche modérée par
Dépêche éditée par
Articles : Les nouveaux processeurs arrivent
Posté par patrick_g (page perso, ). Modéré le 14 février 2007.
Beaucoup de firmes font leurs annonces de produits futurs lors de ce salon et évoquent également les progrès technologiques envisageables à court terme.
Cette année IBM dévoile son Power6, Sun présente son Niagara 2, AMD annonce son futur processeur quad-core Barcelona, PA Semi, un nouvel entrant sur le marché, lance le PA6T. Intel de son coté propose un aperçu des futurs processeurs massivement multicores avec son démonstrateur 80 coeurs.
![[en]](../../../images/en.png)
La conférence ISSCC (377 hits)-
Le Power6 (1379 hits)
-
Le Niagara 2 (1004 hits)
-
Le Barcelona (1089 hits)
-
Le PA6T (1071 hits)
-
Le prototype Intel 80 coeurs (2205 hits)
> Lire la dépêche (59 commentaires, moyenne: 3,6).
Celui-ci est un gros CPU de près de 800 millions de transistors avec gravure en 65 nanomètre. L'architecture est dual-core (avec en plus deux threads par coeur), 128 Ko de mémoire cache de niveau 1 et 4 Mo de niveau 2 par coeur. Il est possible d'adjoindre 32 Mo de L3 partagée.
La grande surprise de ce processeur est sa fréquence de fonctionnement qui sera aux alentours de 5 GHz. C'est la reprise de la course à la fréquence qu'avait abandonnée Intel il y a quelques années.
IBM a optimisé tous les recoins du circuit et a veillé à ce que l'enveloppe thermique reste raisonnable (100 Watts) en fractionnant son CPU en une multitude de zones pouvant travailler à des fréquences différentes.
Le site ArsTechnica présente brièvement ce CPU et le site RealWorld Techno analyse plus en profondeur l'architecture d'IBM.
Sun ayant fait sa révolution il y a deux ans avec sa puce Niagara, il était logique que la firme poursuive sur sa lancée et annonce son Niagara 2. Gravé en 65 nanomètre ses huit coeurs accueillent maintenant huit threads chacun ce qui fait qu'un seul processeur peut gérer 64 threads simultanés !
L'unité cryptographique est toujours présente (elle gère les RC4, AES, DES, 3DES, SHA-1 et le SHA-256) et il y a maintenant une unité à virgule flottante par coeur (alors que dans la génération précédente, il n'y en avait qu'une seule qui était partagée entre les 8 coeurs).
Ce processeur est extrêmement intégré (SiC ou System-on-Chip) puisqu'il comprend 4 contrôleurs mémoire (dual-channel FBDIMM), deux ports ethernet 10 gigabits et 8 ports PCIe sur la surface du CPU.
Encore une fois on peut lire une présentation simplifiée sur Arstechnica et une présentation détaillée sur RealWorld Techno.
AMD a été secoué par les performances du Core 2 Duo d'Intel et l'entreprise de Sunnyvale est bien décidée à reprendre le leadership avec l'architecture K8L. Son futur champion est connu sous le nom de code de Barcelona et sera un quad-core natif en 65 nanomètres avec, pour la première fois dans la gamme Opteron, un troisième niveau de cache mémoire. Sa grande force sera sa capacité de calcul en virgule flottante qui sera très fortement augmentée et sa capacité à s'intégrer dans des machine octo-processeurs en dialoguant par le bus Hypertransport (machines glueless).
Une analyse de l'architecture K8L est disponible ici.
Fondé par des anciens ingénieurs de Digital ayant travaillé sur les processeurs Alpha, la firme PA Semi a choisi de se consacrer au marché de l'embarqué avec des processeurs très puissants utilisant l'ISA PowerC. Leur premier produit, le PA6T, est assez surprenant puisqu'il propose un processeur double-coeur 64 bits cadencé à 2 GHz avec contrôleur mémoire intégré dans une enveloppe thermique de seulement 25 Watts (13 Watts en moyenne).
Ce nouveau CPU est assez innovant par son utilisation massive (plus de 25 000) des clock gates qui servent à réduire dynamiquement la fréquence de certaines parties du coeur et par son unité d'entrées/sorties entièrement reconfigurable.
Un long article est disponible ici sur le PA6T.
Enfin Intel, le géant du processeur, n'ayant pas de produit vraiment nouveau à annoncer lors de cette édition de ISSCC, a choisi de présenter un démonstrateur technologique de CPU 80 coeurs.
La problématique des processeurs multicoeurs du futur se situe dans l'accès à la mémoire. En effet, quand il y a plusieurs dizaines de coeurs qui réclament simultanément des nouvelles données, comment permettre des transferts ayant un débit suffisant ?
Intel a opté pour une solution radicale : superposer une puce multicoeurs et une puce mémoire pour fabriquer un microprocesseur intégré. Ainsi, il n'y aura plus besoin de bus mémoire (FSB) et les accès pourront se faire avec un débit et une vitesse maximum.
Pour expérimenter ce concept Intel a produit un CPU 80 coeurs capable de fournir une puissance de plus d'un teraflop. L'ISA x86 est provisoirement mise de côté pour ce démonstrateur qui utilise une architecture VLIW (comme l'Itanium) afin de minimiser le coût en transistor.
Merci
Merci et bravo pour cette dépêche complète, concise et accessible ! :)
Étienne.
E Ultreïa !
-
[^]Re: Merci
VLIW
VLIW ou EPIC
Je veux dire un compatible EPIC, ou une nouvelle architecture de développement ?
-
[^]Re: VLIW
Posté par patrick_g (page perso, ) le 14/02/2007 à 19:45. (lien). Évalué à 6.Je crois pas que ce soit compatible Itanium car ce dernier est 64 bits alors que les coeurs de la nouvelle puce d'Intel sont en 96 bits.
-
[^]Re: VLIW
Posté par baud123 (Jabber id, page perso, ) le 14/02/2007 à 19:48. (lien). Évalué à 2.stait quoi la question ?
et en français^W anglais, sinon http://en.wikipedia.org/wiki/Very_long_instruction_word
et http://en.wikipedia.org/wiki/Explicitly_Parallel_Instruction(...) (ah si yen a un en français : http://fr.wikipedia.org/wiki/EPIC_%28informatique%29 )
Bel article
Un article bien fait, clair et neutre, c'est pas drôle :-)
Un volontaire qui s'y connait en processeurs pour ouvrir les hostilités et faire l'oracle, et nous dire lequel fera un Flop sans le Tera, lequel fera grille-pain, et lequel raflera le gros lot ?
-
[^]Re: Bel article
Posté par CyrrusSmith (page perso, ) le 14/02/2007 à 22:44. (lien). Évalué à 5.Bon je vais essayer.
Et les DRM?
Il me semble que ce doit être un critère de choix. Il y a des fonction DRM das les puces intel, AMD, et IBM, et normalement pas dans les puces SUN.
La machine du vrai geek ne doit elle pas être avec un ou des processeurs sans DRM?
Et le projet de processeur libre dans tout ça?-
[^]Re: Bel article
Posté par Farvardin (page perso, ) le 15/02/2007 à 06:30. (lien). Évalué à 6.avec un CPU 80 coeurs, je pense que c'est la puce d'Intel qui pourra le mieux gérer les DRM : une pour écouter de la musique de chez Apple, une autre pour écouter de la musique de ces Sony, une autre (non, deux autres) pour regarder des vidéo Universal, une pour jouer à des jeux de chez Microsoft, une pour démarrer une session sous windows etc.
Et le reste (s'il en reste), pour démarrer un navigateur internet (comptez-en au moins 2 pour firefox 3) et aller se plaindre sur linuxfr :)
Sinon merci pour l'article bien détaillé (même si je n'ai pas tout compris), cela donne le tournis tout cela, à noter que le Niagara 1 est celui qui est passé en opensource il me semble :
http://en.wikipedia.org/wiki/OpenSPARC
Continuront-ils dans cette voie avec les nouveaux processeurs ? Est-ce que c'est "utile" pour le moment, et que cela a donné des choses intéressantes dans la voie de la conception de machines entièrement libres ?--
Tous ensemble contre l'esclavitude des logiciels privateurs !-
[^]Re: Bel article
Posté par reno () le 15/02/2007 à 08:52. (lien). Évalué à 3.>Est-ce que c'est "utile" pour le moment,
A part pour ceux qui étudie le CPU, non: les chipset eux ne sont pas libres.
>et que cela a donné des choses intéressantes dans la voie de la conception de machines entièrement libres ?
Même réponse qu'au dessus.-
[^]Re: Bel article
Posté par Farvardin (page perso, ) le 15/02/2007 à 16:19. (lien). Évalué à 3.C'est pas tout récent (2 ans), mais j'ai trouvé cet article intéressant :
http://www.presence-pc.com/tests/Le-Hardware-Open-Source-112(...)--
Tous ensemble contre l'esclavitude des logiciels privateurs !
-
-
-
[^]Re: Bel article
Posté par Zenitram (page perso, ) le 15/02/2007 à 10:15. (lien). Évalué à 6.Il y a des fonction DRM das les puces intel, AMD, et IBM, et normalement pas dans les puces SUN.
Vais essayer de tuer le troll : c'est pas parce que la fonctionnalité est la qu'elle doit etre obligatoirement utilisée.
C'est comme les gens qui fustigent le HDMI et disent "pas de DRM chez moi", le HDMI permet de faire passer un flux crypté, cool, mais si tu n'a pas de flux crypté le HDMI marche aussi!
Bref, l'objet des dRM c'est plus le coté logiciel et contenu, pas CPU ;-)-
[^]Re: Bel article
Posté par hervé Couvelard (Jabber id, page perso, ) le 22/02/2007 à 12:32. (lien). Évalué à 2.C'est pas parce que tu as une arme chez toi qu'elle doit obligatoirement être utilisé.
je trouve qu'un char de l'armée dans mon jardin serait vachement cool comme terrain de jeux pour les enfants (oui je pars avec les clés la journée).
C'est parce qu'un ancien pédophile a été comdamné qu'il va récidiver. Une fois a dette payée, il n'y a pas de raison que tu ne puisse pas être instit.
ok, ok
-
-
-
[^]Re: Bel article
Posté par reno () le 15/02/2007 à 06:32. (lien). Évalué à 5.OK:
-la capacité flottante amélioré des K8L (traitement des instructions SSE en 1 cycle) ne fait que rattraper ce qu'Intel a fait sur les processeurs Core il me semble, donc pas vraiment de quoi s'extasier.
-Le terme de 'coeur' pour le démonstrateur Intel avec ses 80 coeurs me parait potentiellement trompeur: ce n'est pas vraiment un CPU complet: il n'y a même pas d'unité pour faire des calculs entiers..
Bon il y a de la mémoire locale, des registres, mais c'est très différent d'un 'coeur' x86 normal.. Il faut trouver un meilleur terme: 'coeur simplifié dédié aux calculs flottant', c'est un peu long..-
[^]Re: Bel article
Posté par lasher () le 15/02/2007 à 08:18. (lien). Évalué à 6.Intel parle de « tile » (tuile). Et de façon générale, 80 coeurs c'est très bien, c'est le futur, le progrès, tout ça, mais presque personne ne sait programmer efficacement en parallèle. Si on prend le quadcore qu'Intel a sorti récemment, qui comprend 2 x 2 coeurs, avec les caches partagés 2 à 2, j'aimerais bien qu'on m'explique comment on espère optimiser « facilement » des programmes pour ce genre d'architecture. Je n'ose même pas imaginer ce qu'il va en être pour 80 coeu^Wtuiles.
-
[^]Re: Bel article
Posté par Pol' uX () le 15/02/2007 à 08:48. (lien). Évalué à 5.Ce genre d'architecture n'est pas conçue pour des applications grand public, mais pour imiter les grilles de calcul en plus performant.
Les théories utilisées pour le développement d'applications de calcul distribuées sont adaptées à ce genre d'architecture.
Moralité, on n'optimise pas un programme pour ce truc, on le conçoit aux petits oignons ... c'est pour ça que tu n'est pas près d'en avoir un chez toi !--
Soutenez le logiciel libre, en adhérant dès maintenant à l'April-
[^]Re: Bel article
Posté par lasher () le 15/02/2007 à 10:57. (lien). Évalué à 4.« Ce genre d'architecture n'est pas conçue pour des applications grand public, mais pour imiter les grilles de calcul en plus performant. »
Alors, déjà, je suppose que tu voulais parler de grappes ( « clusters » ), parce que les grilles, c'est autre chose. Ensuite, je sais très bien à quoi sert une machine massivement parallèle, et comment on programme pour elle. Quant aux théories pour développer du calcul parallèle ou distribué sur ce genre de machines, je n'y crois pas un instant. Il existe des tas d'algorithme théoriquement géniaux, mais qui supposent qu'on peut avoir accès à tout un tas de mécanismes non moins géniaux (par exemple, lorsque tu effectues un calcul et que tu le parallélise, si tu as besoin de synchroniser une partie de tes calculs à chaque étape de l'algorithme, tu te retrouves avec un GROS goulot d'étranglement.)
De plus, le problème de la localité (utilisation des caches) et de la bande-passante mémoire devient critique dans ce genre d'architectures, et je me répète, très peu de personnes sont capables d'optimiser un programme pour ce genre d'architecture (et c'est aussi valable pour les gros clusters qui existent de ci de là).
Maintenant, si tu reprends ce que je dis, je faisais remarquer que même pour un 2 x 2 coeurs, c'était loin d'être évident.
-
[^]Re: Bel article
Posté par Vincent Danjean () le 16/02/2007 à 08:43. (lien). Évalué à 3.Moralité, on n'optimise pas un programme pour ce truc, on le conçoit aux petits oignons ... c'est pour ça que tu n'est pas près d'en avoir un chez toi !
Ça dépend de quoi tu parles. Si c'est du programme applicatif, celui qui fait les calculs (calculs d'écoulement de fluides autour d'une voiture ou d'un avion, calculs de propagation d'ondes, ...), alors généralement non. Le but de ces programmes (écrits par les grosses entreprises) est d'avoir un code qui tournera pendant 20 ans. Donc on ne l'optimise pas pour une architecture particulière. Mais on l'écrira de manière à ce qu'il puisse être parallélisé facilement/efficacement.
On l'écrira donc en utilisant des couches de portabilité sur des environnements plus ou moins standards et/ou libres comme MPI ou PM2 ( http://runtime.futurs.inria.fr/pm2/ ). Et ces environnement là seront effectivement optimisés pour l'architecture ciblée.-
[^]Re: Bel article
Posté par vsin () le 16/02/2007 à 20:20. (lien). Évalué à 6.Bonsoir,
On l'ecrira aussi pour qu'il quantifie les erreurs de calculs des differentes plateformes.
J'ai vue le CEA a Grenoble disqualifier des plateformes parce que le resultat d'un calcul type sortait de la limite de tolerance acceptable par les chercheurs.
Un CPU ne sait pas calculer parfaitement, il y a toujours des effets de bords qui peuvent deriver et non se corriger.
Et ce qui est marrant, c'est de voir les constructeurs defiler avec leurs supers machines et se voir attribuer des notes et parfois meme de la remarque : "Votre machine ne sait pas calculer, elle ne vaut rien".
-
-
-
[^]Re: Bel article
Posté par reno () le 15/02/2007 à 08:57. (lien). Évalué à 3.>comment on espère optimiser « facilement » des programmes pour ce genre d'architecture.
Bin pour un serveur avec plein de clients, ce n'est pas compliqué..
Et ces processeurs 2*2 sont plutot prévus pour des serveurs.
Maintenant, paralleliser des jeux oui c'est tres compliqué, d'ailleurs tout ceux qui sont vendus a l'heure actuelle n'exploite pas du tout le parallélisme.-
[^]Re: Bel article
Posté par lasher () le 15/02/2007 à 11:30. (lien). Évalué à 9.« Bin pour un serveur avec plein de clients, ce n'est pas compliqué..
Et ces processeurs 2*2 sont plutot prévus pour des serveurs. »
Euh, non. Des stations de travail avec deux processeurs comportant chacun deux coeurs, ça existe déjà, et ne sont clairement pas destinées à faire office de serveurs.
Le côté « serveur » de la chose existe à cause du prix qu'on constate maintenant, mais d'ici un an, lorsqu'Intel et AMD auront sorti leurs octo-coeurs, Apple et Dell proposeront très certainement dans leur catalogue des machines avec 4 coeurs (en fait, Dell en propose déjà).
Concernant les jeux vidéo, ça fait un bail que les programmeurs se posent la question de l'optimisation. Mais si pour un serveur, se contenter du fait que chaque coeur peut faire tourner un ensemble de threads indépendants est suffisant (et encore, ça dépend de l'application), pour les applications de tous les jours, c'est moins évident. Désormais, il va falloir apprendre à programmer correctement avec les threads, et franchement, il y a pas mal de gens dans l'industrie qui ne savent pas le faire efficacement (je ne parle même pas d'optimisation à ce stade).
Donc oui, la question de « comment va-t-on programmer efficacement sur ce genre d'architecture » me semble plutôt pertinente. Surtout si tu prends en compte certains effets « rigolos » qui peuvent se produire si on se retrouve avec une éviction des lignes de cache successives, due à une mauvaise exploitation de la localité dans les threads. Le système pourrait s'en trouver ralenti au lieu d'accéléré.
Bref. Je radote, j'arrête. :-)-
[^]Re: Bel article
Posté par Ontologia (page perso, ) le 15/02/2007 à 13:30. (lien). Évalué à 4.Je plussoie, le multicore étant inéluctable, il faudra programmer en concurrence, et il faut en tirer les conséquences :
Il faut trouver un modèle moins problématique que les thread.
Les thread c'est trop compliqué, c'est trop bas niveau, et faut pas rêver on aura jamais une majorité de programmeurs qui sauront maîtriser cette technique à la perfection ou tout au moins à bon niveau.
Comme c'est trop compliqué il faut proposer une couche d'abstraction, et refiler la difficulté au compilateur.
On a différent modèle pour cela, et un des plus intéressant est sans doute SCOOP(Simple Concurent Object Oriented Programming), qui est surement un bon départ à améliorer.
La meilleur description que j'en connais est une thèse de 100 pages, mais le principe général est expliqué au début :
http://cs.anu.edu.au/people/Richard.Walker/eiffel/scoop/mc-t(...)
En gros l'idée, c'est d'ajouter un mot clé au langage objet, en Eiffel, B. Meyer a choisi separate. Un objet separate voit son exécution parallélisé si son appel est non bloquant(ie pas de valeur de retour).-
[^]Re: Bel article
Posté par Vador Dark (Jabber id, ) le 15/02/2007 à 14:37. (lien). Évalué à 4.Et ne peut-on pas imaginer que le compilo puisse s'occuper seul de la parallèlisation?
Serait-il complexe de gérer la dépendance des instructions les unes aux autres?
Un simple arbre de dépendance du code ne permettrait-il pas au compillo de créer des genres de threads pour répartir le contenu d'une fonction ou d'un programme dans sa globalité entre plusieurs coeurs, en recherchant à avoir un minimum d'échange entre eux?-
[^]Re: Bel article
Posté par d-jo (page perso, ) le 15/02/2007 à 15:36. (lien). Évalué à 5.>Et ne peut-on pas imaginer que le compilo puisse s'occuper seul de la parallèlisation?
Peut-on surtout imaginer qu'il en soit autrement ? Franchement, si l'utilisation correcte de la machine (je parle pas de trucs supers, juste le fait qu'il y ait plusieurs coeurs et qu'on les utilises), dépend des qualitées du programmeur, il risque d'y avoir des transitors qui choment.
Le problème étant bien sur d'avoir un nouveau modèle de programmation, compatible avec l'existant (la révolution c'est bien mais s'il faut tout réécrire personne ne changera sa façon de travailler) et qui soit intelligible par le programmeur de base.-
[^]Re: Bel article
Posté par Bruno Muller (Jabber id, page perso, ) le 15/02/2007 à 16:23. (lien). Évalué à 1.Il existe la lib OpenMP, http://www.openmp.org/drupal/ pour faciliter le dev d'applications multi-threadés.
C'est pas encore complètement transparent, mais ça aide déjà beaucoup :)-
[^]Re: Bel article
Posté par lasher () le 15/02/2007 à 17:15. (lien). Évalué à 3.Bof. Ça marche pas mal quand ta boucle possède déjà de très bonnes propriétés de parallélisation. De plus, même sur des cas très étudiés (bibliothèques d'algèbre linéaire, etc.),on a un problème de passage à l'échelle. Alors sur 2 ou 4 coeurs, ce n'est peut-être pas très grave, mais quand il s'agit de faire tourner en parallèle plusieurs threads sur plusieurs processeurs, eux-même multi-core, chaque coeur pouvant être muni d'un dispositif SMT, ça commence à faire beaucoup de niveaux de parallélisme à prendre en compte.
Les implémentations actuelles d'OpenMP sont relativement décevantes, notamment parce que pour des raisons « pratiques », plusieurs synchronisations sont effectuées même lorsqu'on pourrait s'en passer (sauf qu'il faut être humain pour le savoir :-) ).
Donc la parallélisation automatique, sauf dans des cas très précis, je n'y crois pas trop dans un avenir immédiat. Par contre, ajouter à des langages des primitives permettant de gérer correctement les threads serait clairement un plus.-
[^]Re: Bel article
Posté par Julien () le 15/02/2007 à 17:32. (lien). Évalué à 1.Dans le domaine des langages pour applications paralleles, le dernier de sun (FORTRESS) est relativement interessant.
http://research.sun.com/projects/plrg/faq/index.html
http://en.wikipedia.org/wiki/Fortress_programming_language
-
-
-
-
[^]Re: Bel article
Posté par Ontologia (page perso, ) le 15/02/2007 à 16:56. (lien). Évalué à 2.Non pas totalement car il existe des ambiguité sémantique.
Il faut expliquer très clairement au compilateur que là, le calcul est indépendant, mais que par contre 300 lignes plus loin, il faudrai attendre que ce soit fini, etc...
Soit tu prend un parti pris comme SCOOP ou en gros tu dis, si valeur de retour => bloquant et paralèlle sinon, ou sois tu crée toute une sémantique pour décrire avec précision ce que tu veux.
J'y pense, peut-être des pistes du côté d'Erlang ?-
[^]Re: Bel article
Posté par Albert () le 15/02/2007 à 19:22. (lien). Évalué à 2.question stupide probablement mais qu'en est il du HPF pour ce genre de problematique?
http://hpff.rice.edu/index.htm
Il me semblait que c'etait un peu fait pour et puis le fortran a beaucoup de defaut mais bon il a ete prevu pour faire du calcul a la base-
[^]Re: Bel article
Posté par Julien () le 15/02/2007 à 23:10. (lien). Évalué à 1.Oui, HPF, OpenMP, et les 3 langages qui ont été développés pour répondre a l'ARPA (Fortress X10 et Chapel) sont destinés à répondre à ces problèmes.
En fait, ils permettent surtout d'exploiter le parallélisme des boucles (au moins pour les 2 premiers très proches dans l'idée)
Parmis les 3 plus récent, j'aime beaucoup l'idée de Fortress : écrire un programme en langage mathématique ou presque et en extraire le parallélisme ensuite.-
[^]Re: Bel article
-
-
-
-
[^]Re: Bel article
Posté par Vincent Danjean () le 16/02/2007 à 08:31. (lien). Évalué à 7.Et ne peut-on pas imaginer que le compilo puisse s'occuper seul de la parallèlisation?
La réponse est non si on veut que la parallélisation soit efficace.
Il y a eu beaucoup (BEAUCOUP) de travaux de recherche sur ce thème. Je ne connais pas une seule équipe qui soutient encore que la parallélisation peut être faite entièrement automatiquement.
Par contre, il est certain que le compilateur et/ou le runtime peuvent aider grandement le programmeur en lui fournissant des outils ou des analyses partielles. La plupart des travaux de recherche sur le parallélisme que je connais vont dans cette direction.
Un programmeur a trop l'habitude d'une exécution séquentielle et d'une mémoire partagée pour qu'un outil puisse extraire automatiquement une version parallèle efficace de son programme en respectant exactement la sémantique du code séquentiel. Dès que le programmeur commence à mettre des annotations (ie dans cette fonction, je ne touche pas à l'état globale, je me contente de lire sans écrire ces variables, ...), une parallélisation automatique devient beaucoup plus envisageable.
Le compilo restera très utile pour détecter le parallélisme au niveau instruction (et remplir correctement les différentes unités de calcul du processeur ciblé). Mais il ne sera pas capable de paralléliser efficacement sans aide un programme 'classique'.
-
-
[^]Re: Bel article
Posté par Raphaël Gertz (page perso, ) le 15/02/2007 à 15:19. (lien). Évalué à 3.Une petite question :
- Y a-t-il des des documents concrets sur comment faire en C/C++ ce genre de chose ?
Je connais pas trop mal le système de thread (pthread), mais j'aimerais me perfectionner sur comment améliorer l'architecturage d'un programme, les choses a penser, les erreurs a éviter, etc...-
[^]Re: Bel article
Posté par Matthieu C () le 15/02/2007 à 19:11. (lien). Évalué à 2.Y a-t-il des des documents concrets sur comment faire en C/C++ ce genre de chose ?
Il y a par exemple Athapascan (http://www-id.imag.fr/Logiciels/ath1/).
Bon courage :)-
[^]Re: Bel article
Posté par Vincent Danjean () le 16/02/2007 à 08:22. (lien). Évalué à 2.Athapascan1 n'est qu'une interface (simplifiée) de Kaapi maintenant.
La référence officielle est désormais cette page :
http://kaapi.gforge.inria.fr/
[la page du site d'www-id sera bientôt une redirection là bas]
Une nouvelle release de kaapi devrait être faite d'ici quelques semaines.
L'idée de kaapi/athapascan est que le programmeur décrit les dépendances entre les fonctions/modules de son programme. Le runtime kaapi s'occupe ensuite tout seul de l'exécuter en parallèle sur la ou les machines à sa disposition. Évidemment, c'est destiner à paralléliser des programmes de calcul. Si on veut des affichages graphiques (ou tout autre E/S sur une machine particulière), ça marchera moins bien (kaapi ne pourra pas déporter ces parties du calcul). Et bien sûr, kaapi ne trouvera pas de parallélisme s'il n'y en a pas dans le programme (ie dans la description des dépendances entre tâches).
-
-
[^]Re: Bel article
Posté par lasher () le 16/02/2007 à 00:12. (lien). Évalué à 5.En ce qui concerne les threads, et en particulier l'implémentation des pthreads (au moins sur linux), le problème est surtout la performance affichée de la bibliothèque fournie. Un autre problème est que les pthreads sont des threads système - ce qui dans le cadre de certaines applications se justifie tout à fait, et est même conseillé - mais avoir des bibliothèques de threads en espace utilisateur peut aussi avoir son intérêt (l'idéal étant évidemment l'utilisation de threads à 2 niveaux : système et utilisateur) : lorsqu'il y a beaucoup de changements de contexte à effectuer, une bibliothèque de threads en espace utilisateur ira bien plus vite (pas besoin de faire un appel système, d'appeler l'ordonnanceur, puis de repasser en mode utilisateur). Mais on peut évidemment trouver des exemples où l'appel à des threads système se révèle plus avantageux (par exemple, si de toute manière il faut faire une entrée/sortie, et que le programme a tendance à en faire beaucoup, alors comme de toute manière on passera par le système, autant passer la main à un autre thread/processus en attendant que la donnée soit écrite ou lue).
Pour ce qui est d'architecturer une application multi-thread, je ne suis pas certain que tu aies besoin de bouquins si différents de ceux qui traitent d'algorithmique parallèle en règle générale, et des threads POSIX en particulier. Après, tout est histoire d'implémentation, et le fait est qu'entre celle de Sun et celle de Linux, il y a un monde. Donc même avec un programme portable (car utilisant les pthreads), les performances risquent de beaucoup varier (par exemple, sous Linux, un thread et un processus ne sont pas fondamentalement différents, alors que sous Solaris, qui implémente une bibliothèque hybride, si).
-
-
-
-
[^]Re: Bel article
Posté par Matthieu C () le 15/02/2007 à 19:09. (lien). Évalué à 3.Bin pour un serveur avec plein de clients, ce n'est pas compliqué..
Et ces processeurs 2*2 sont plutot prévus pour des serveurs.
C'est pas si evident que ca : il peut y avoir un goulet du niveau des IO. Par exemple 4 coeurs qui font des io que un meme disque...
-
-
[^]Re: Bel article
Posté par Laurent GUERBY (page perso, ) le 15/02/2007 à 21:05. (lien). Évalué à 1.Au boulot 6.8 de speedup pour notre appli de calcul numérique sur un bi-quad core intel, soit 85% du max théo (et 6.5GB de RAM utilisé).
Donc si si, ça peut servir :).
-
-
A quand une course à la puissance...
Très bon article, vraiment !
De mon côté, je me demande quand commencera la course à la puissance électrique, quand commenceront nous à ne plus courrir après les 10^n flops pour courrir après les composant les plus économiques sur le plan de l'énergie.
Nos ordinateur (je parle surtout des machines perso, mais c'est surement valable aussi au niveau des serveurs) consomment toujours plus, demandent toujours plus d'énergie.
L'énergie, c'est précieux, il me semble qu'il serait bon de l'économiser au mieux, en oriantant les recherche sur un nouvel axe...
Mais bon... c'est peut-être un peu utopique de ma part...
I see dead pixels
-
[^]Re: A quand une course à la puissance...
Posté par Zenitram (page perso, ) le 15/02/2007 à 10:18. (lien). Évalué à 7.quand commenceront nous à ne plus courrir après les 10^n flops pour courrir après les composant les plus économiques sur le plan de l'énergie.
Ca existe, donc tu peux choisir.
maintenant, faut que la population accepte la perte de performance, et ca c'est pas gagné...
(mon "serveur" a la maison est a base de Via C7, ca marche nickel. Mon serveur sur Internet est aussi avec du C7, ca permet a mon hebergeur de baisser les couts electriques, donc mes couts!)-
[^]Re: A quand une course à la puissance...
Posté par Drakho (Jabber id, ) le 15/02/2007 à 10:49. (lien). Évalué à 6.Oui, ça existe, c'est vrai (j'ai aussi fait ce choix)
mais c'est rarement indiqué de façon claire sur le produit, c'est pas forcement facilement accessible (VIA uniquement accessible / commandable via le net, chez moi...)
Mais entre trois pékins qui consomment moins et toute une industrie qui change d'axe, il y a une différence...
Et, selon moi, la population accepte ce qu'on lui propose, ce qu'on lui avance, ce pour quoi on fait de la pub.
Si les commerciaux mettent la puissance de calcul en avant (il n'y a qu'a voir le parallel avec les appareils photos et le nombre de pixels), les consomateur suivront cette course avec la frénésie qu'on leur connait
Que l'axe de communication des équipes commerciales changent et le comportement des consomateurs changera lui aussi.--
I see dead pixels-
[^]Re: A quand une course à la puissance...
Posté par lasher () le 15/02/2007 à 11:40. (lien). Évalué à 3.Il y a déjà tout un tas d'articles essayant d'établir un lien direct entre la consommation d'énergie d'une puce CMP (multi-core), SMT (multi-thread, type hyper-threading d'intel, ou bien ce qu'on trouve dans les power 5 et 6 d'IBM), et le mono-core. L'objectif avoué de ces papiers est d'obtenir le meilleur compromis entre performance, consommation électrique, et dissipation thermique. Patience, nous n'en sommes qu'au début. :-)
-
[^]Re: A quand une course à la puissance...
Posté par blackshack (page perso, ) le 15/02/2007 à 11:49. (lien). Évalué à 4.Question un peu liéée, vous savez on l'on peut trouver une liste et un comparatif de machines, CPU, .... économique/écologique?
-
-
-
[^]Re: A quand une course à la puissance...
Posté par pasBill pasGates () le 16/02/2007 à 00:46. (lien). Évalué à 3.Ca a deja commence. Tous les datacenters(Google notamment) font tres attention a ca car ca leur coute des sommes enormes en refroidissement et consommation electrique.
Merci pour l'article et petite question ...
Merci pour cet article très clair.
Juste une petite question pour un programmeur qui n'y connait rien sur le fonctionnement réel des procs : tout le monde dit que pour tirer avantage des procs multicoeurs il faut paralléliser le code, est-ce que ca veut dire qu'un proc double coeur ne peut exécuter qu'un programme à la fois (ce programme ayant 2 threads ?) ou est-ce qu'il peut exécuter plusieurs programmes différents en parallèle ?
Car si on peut exécuter plusieurs programmes en parallèles, je ne vois pas où est la polémique "paralléliser/pas paralléliser" car on a tous plusieurs dixaines de programmes qui tournent sur une machine donc un proc multi-coeurs va - de toute façon - accélérer le tout.
Qu'est-ce qui est petit, rond et vert, qui monte et qui descend ?
Yoda qui fait le con avec la force.
-
[^]Re: Merci pour l'article et petite question ...
Posté par Vincent Danjean () le 16/02/2007 à 09:00. (lien). Évalué à 10.Pour utiliser des CPU (ou coeurs) différent, il faut que le flot d'exécution soit géré par le noyau. C'est le cas des programmes classiques (monothreadés) ainsi que, pour le programmes multithreadés, des threads dits de niveau noyau. La bibliothèque de threads de linux ne propose que des threads de niveau noyau. Donc linux est capable d'assigner aux différents processeurs (ou coeurs) indifféremment un processus classique (monothreadé) ou un thread d'un processus multithreadé.
on a tous plusieurs dixaines de programmes qui tournent sur une machine donc un proc multi-coeurs va - de toute façon - accélérer le tout.
Regarde bien l'occupation de ton processeur (il y a plein d'applets pour ça). Tu verras qu'il passe une très grande partie de son temps à ne rien faire. Tu as beau avoir plein de processus 'qui tournent', ces processus sont généralement en attente d'événements (clic, touche clavier, timer, ...) et ils n'ont alors pas besoin du processeur.
Et quand ton processeur est vraiment occupé, il n'y a généralement alors qu'un seul programme qui en a besoin à ce moment (par exemple gcc peut facilement occuper 100% du CPU). Et pour accélérer ce programme (et te faire l'impression que ta machine va plus vite), alors il faut que ce programme utilise des threads. Il y a rarement plusieurs programmes qui tournent (au sens utilisent vraiment le CPU) systématiquement en même temps.
L'exception la plus classique est le serveur X qui doit répondre en même temps que tes applications quand ces dernières ont des choses à faire. Dans ce cas, avoir deux CPU permet effectivement au noyau de répartir ces deux tâches (l'application et le serveur X). On aura alors l'impression d'une amélioration beaucoup plus grande entre le passage de 1 à 2 CPU que de 2 à 4.
Avoir des CPU supplémentaires peut aussi être utile si tu as des programmes en tâche de fond qui consomment vraiment du CPU (lecteur mp3/divx, encodage mp3/divx, indexation automatique des documents de ta machine, ...)-
[^]Re: Merci pour l'article et petite question ...
Posté par Emilien Kia (Jabber id, page perso, ) le 16/02/2007 à 09:43. (lien). Évalué à 1.Merci pour les réponses.
--
Qu'est-ce qui est petit, rond et vert, qui monte et qui descend ?
Yoda qui fait le con avec la force.
-
-
[^]Re: Merci pour l'article et petite question ...
Posté par Julien () le 16/02/2007 à 09:08. (lien). Évalué à 4.Deux processus peuvent sans problème tourner sur les deux coeurs.
Tu as effectivement en général entre 50 et 100 processus qui tournent sur un PC de base (au bas mot).
Seulement ces processus n'utilisent pas, ou presque, le processeur. Par exemple crond qui est compté parmis ces processus passe son temps dans des sleep() il n'est donc schedulé au pire qu'une fois par minutes pour quelques millisecondes d'utilisation processeur.
Tu n'as en fait qu'un ou deux processus qui utilisent vraiment le processeur (cherche dans un top le nombre de processus qui dépassent les 1% d'utilisation processeur ...)
La question de la parallélisation se pose donc bien !
-
[^]Re: Merci pour l'article et petite question ...
Posté par Thomas Pornin () le 20/02/2007 à 12:01. (lien). Évalué à 4.Il y a deux notions importantes :
- "fil d'exécution" : c'est la suite d'instructions que le processeur parcourt et exécute en séquence.
- "espace d'adressage" : c'est la vision de la mémoire d'un processus.
Les espaces d'adressage des processus sont distincts, et chaque processus ne peut taper que dans le sien (sinon c'est segfault). On appelle "MMU" le morceau du processeur qui gère l'espace d'adressage (localisation en mémoire -- ou pas, en cas de swap ; droits d'accès ; etc). Il peut y avoir des morceaux de RAM communs entre plusieurs espaces d'adressage (mémoire partagée, comme on dit) mais la règle commune reste la séparation des espaces.
Un processus, c'est un espace d'adressage, et un certain nombre de fils d'exécution qui travaillent dans cet espace. Ces fils d'exécution, quand ils sont au moins deux, on les appelle des threads.
Dans un processeur multi-coeurs, chaque coeur peut gérer un espace d'adressage à la fois. Donc deux processus distincts peuvent tourner en parallèle, un sur chaque coeur. Chaque coeur peut en outre gérer plusieurs fils d'exécution plus ou moins en même temps (ce qu'Intel appelle "hyper-threading"), mais là c'est forcément dans le même espace d'adressage (la MMU de chaque coeur ne peut prendre en compte qu'un seul espace d'adressage à la fois), donc ces fils d'exécution ne peuvent être que des threads du même processus.
En bref, le multi-coeurs, on peut en profiter pour des processus distincts, mais pour l'hyper-threading, il faut des threads au sein d'un même processus. Les deux mécanismes sont proposés par les processeurs récents. Pour profiter à fond de ces processeurs, il faut avoir plusieurs threads, mais le multi-coeur aide déjà quand on a plusieurs processus indépendants.-
[^]Re: Merci pour l'article et petite question ...
Posté par lasher () le 20/02/2007 à 12:21. (lien). Évalué à 3.L'aide du multi-coeur est très limitée si tu te contentes des applications , tu ne vas pas aller bien loin. Le multi-coeur peut aussi servir pour héberger les différents threads d'un même processus - ou de processus différents, évidemment. C'est d'autant plus vrai que, sous linux, un processus et un threads sont quasiment identiques.
-
Utile ? OUI!
Face à tant de commentaires dubitatifs, je rappelle seulement que une Mandriva avait un indexeur de documents qui bouffait toutes les ressources. Bien sûr, c'était un bug, mais avec un système multi-coeur, on n'aurait rien senti. Et finalement, c'est ce qu'apporte la puissance depuis longtemps : rendre l'informatique plus tolérante à l'erreur/imperfection humaine : les logiciels sont de moins en moins optimisés, et pourtant de plus en plus beaux etc. Car à part pour l'esthétique du beau code, on s'en fiche de savoir si c'est optimisé ou pas.
Moi je suis béat devant mplayer qui me lit des DivX sur Pentium 133, mais ce n'est pas l'utilisation quotidienne réèele de l'informatique, sinon MS n'existerait pas.
-
[^]Re: Utile ? OUI!
-
[^]Re: Utile ? OUI!
Posté par pasBill pasGates () le 18/02/2007 à 02:55. (lien). Évalué à 4.Bien sûr, c'était un bug, mais avec un système multi-coeur, on n'aurait rien senti. Et finalement, c'est ce qu'apporte la puissance depuis longtemps
Ben justement si, t'aurais senti a peu pres exactement la meme chose, voire meme pire, parce que l'indexeur il bouffe principalement des I/O pas du CPU. Avec du multi-core si ca se trouve il aurait eu plus de temps CPU, donc plus de chances d'effectuer des I/O, augmentant la charge sur le HD, et tu te serais retrouve avec une machine qui semble plus lente.-
[^]Re: Utile ? OUI!
Posté par _alex () le 18/02/2007 à 11:18. (lien). Évalué à 1.Par contre, lorsque j'avais un biceleron et qu'un programme bouffait 100% d'un CPU (compilation par exemple), c'était assez sympa de pouvoir continuer à utiliser la machine sans trop de ralentissement.
-
[^]Re: Utile ? OUI!
Posté par pasBill pasGates () le 18/02/2007 à 21:36. (lien). Évalué à 2.Tout a fait, j'etais exactement dans la meme situation et c'est ce qui m'a conduit a avoir 2 cartes-meres bi-Celeron Abit de suite, c'est hyper agreable de ce cote la.
-
[^]Re: Utile ? OUI!
Posté par Ph Husson (page perso, ) le 18/02/2007 à 23:42. (lien). Évalué à 1.Hum ...
En mono processeur, mono coeur j'ai aucun problème quand un processus bouffe 100% du cpu....
À la limite quand ils commencent à être beaucoup à faire ca, ca bloque
Non moi ce qui me bloque vraiment c'est les E/S, et ionice est très efficace pour ca (mise à jour de ma distribution sans perturber le moins du monde amarok.) !
-
-
-
[^]Re: Utile ? OUI!
Posté par darkleon (page perso, ) le 20/02/2007 à 12:52. (lien). Évalué à 2.Moi je suis béat devant mplayer qui me lit des DivX sur Pentium 133
Je suis assez surpriss, parce que même avec le meilleur programmeur au monde, pour certaines tâches on a besoin d'une puissance CPU minimum pour fonctionner en temps réel.
Il me semblait qu'il fallait au moins ~400mhz sur un x86 (en puissance brute) pour décompresser du mpeg4 sans perte d'images en résolution DVD (~700x500). D'ailleurs c'est généralement le test qui est fait sur les CM VIA EPIA et elles ont du mal dans les plus basses fréquences.
De même que décompresser un mp3 en temps réel était impossible en dessous de ~60mhz lors de l'arrivé des premiers programmes (Il y a peut être des demos maker qui l'on fait à la mimine en ASM, mais bon).
Sur mon P233MMX, j'utilisais gogonacoda pour encoder les mp3 car c'est le seul qui marchait en "temps réel" (1h de musique->1h de compression). Et il était 3 à 10 fois plus rapide que les progs concurents sur la même machine.
On le voit bien au niveau des algo 3D, ce qui mettait plusieurs heures de calculs pour une image en gouraud ou phong sur mon amiga 500, maintenant je peux le voir en temps réel a plusieurs centaines de FPS sur une carte GFX de base.-
[^]Re: Utile ? OUI!
Posté par José JORGE (Jabber id, page perso, ) le 20/02/2007 à 13:06. (lien). Évalué à 1.J'ai dit DivX, j'ai pas dit la résolution ;-) Effectivement, c'était du 320x240 je crois, ce qui divise par quatre grosso modo les besoins en puissance. La lecture d'un ogg prend 40-50% d'un CPU P133, alors que le mp3 ne prend que 30% À LA LOUCHE.
Bref, le multi-core sera très bien pour faire le DJ avec 32 lecteurs de musique simultanés. En fait, c'est peut-être le client léger X (ou FreeNX) qui va retrouver de l'intérêt pour un usage privé : une seule machine, utilisée en local pour les jeux, et à distance pour tout le reste.
-
Cette page a été générée par Templeet en 0.2092s (dont 0.0287 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.