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 (380 hits)-
Le Power6 (1381 hits)
-
Le Niagara 2 (1006 hits)
-
Le Barcelona (1093 hits)
-
Le PA6T (1075 hits)
-
Le prototype Intel 80 coeurs (2208 hits)
> Lire la dépêche (59 commentaires, moyenne: 3,6).
Vous avez demandé le commentaire #804423.
Run by 
Cette page a été générée par Templeet en 0.1021s (dont 0.0093 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
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
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?
Il existe pour chaque problème complexe une solution
simple, directe et fausse.
H.L. MENCKEN
[^]Re: Bel article
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 ?
You can't grep dead trees...
[^]Re: Bel article
>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
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(...)
You can't grep dead trees...
[^]Re: Bel article
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
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
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
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
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
« 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
Ç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
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
>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
« 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
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
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
>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
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
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
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
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
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
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
j'aime beaucoup l'idée de Fortress : écrire un programme en langage mathématique ou presque et en extraire le parallélisme ensuite.
Ca fait pas un peu double emploie avec fortran + HPF?
[^]Re: Bel article
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
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...
site perso : http://rapsys.free.fr/
[^]Re: Bel article
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
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
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
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
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 :).