Le journal en question a une bonne réputation de sérieux dans le milieu du matériel et permet de comprendre ce qui s'y fait.
L'article évoque les différents choix qui ont été faits pour bâtir le processeur. On apprends également que 2 CPU sont présents sur chaque puce. On apprends aussi qu'ils produisent des modules à base de 4 puces.
Un octo POWER 4 ! J'en veux un !
Aller plus loin
- L'article (7 clics)
- Le dernier exemplaire (2 clics)
- Le journal (3 clics)
# Commun des mortels ?
Posté par djrom . Évalué à 10.
Quand on commence à causer de crossbar, de "multilevel branch-prediction scheme", de LSU ou d'ISU sans explication, je doute qu'une personne avec des connaissance normales (c'est à dire quasi-nulles) dans le domaine des microprocesseurs puisse suivre.
De même, des phrases genre "To help mitigate the effects of the long pipeline necessitated by the high-frequency design, POWER4 invests heavily in branch-prediction mechanisms" ne sont pas vraiment évidentes en soi.
En somme, l'article est très très intéressant, mais il faut AMHA une certaine connaissance en design de micro-p pour comprendre.
P.S nicO, il ne faut pas confondre "membres de la ML F-Cpu" et "commun des mortels". c'est mal :-)
[^] # Re: Commun des mortels ?
Posté par vazco . Évalué à 10.
http://www.realworldtech.com/page.cfm?AID=RWT101600000000(...)
[^] # Re: Excellent lien
Posté par Pierre Jarillon (site web personnel) . Évalué à 10.
L'avenir est-il dans le passé ? La lecture de cet article m'a rappelé le fonctionnement du "transputer" d'INMOS qui était lié par 4 bus à ses voisins. Ce projet racheté par Thomson semble abandonné anisi que son langage occam.
Encore une bonne affaire qui, après CII et Bull est à imputer à nos dirigeants.
[^] # Re: Excellent lien
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Bref, il aurait eu sa chance si il avait été plus puissant dés sa sortie.
"La première sécurité est la liberté"
[^] # Re: Excellent lien
Posté par TSelek . Évalué à 2.
[^] # Re: Commun des mortels ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
Bof, cela veux simplement dire qu'ils ont améliorés l'algo de prédiction de branchement pour masquer l'effet des latences dû au long pipeline (lorsqu'il y a une mauvaise prédiction il faut vider le pipeline donc on perd un nombre de cycle égal à la longueur du pipeline).
Je pense qu'il doit y avoir des passage plus hard que cela !
Désolé sinon pour le autres.
nicO
"La première sécurité est la liberté"
[^] # Re: Commun des mortels ?
Posté par the_freeman . Évalué à 7.
Et en français, ça donne quoi.
Non, franchement, c'est peut être très clair pour toi qui est plongé là dedans, mais pour un novice, c'est incompréhensible.
[^] # Re: Commun des mortels ?
Posté par djrom . Évalué à -5.
[^] # Re: Commun des mortels ?
Posté par Thomas Cataldo (site web personnel) . Évalué à 10.
[^] # Re: Commun des mortels ?
Posté par Cru Kilu . Évalué à 0.
Du moment que vous lisez régulièrement linuxfr depuis quelques mois, ce n'est pas possible d'ignorer ce qu'est un pipeline.
Le mécanisme de prédiction est facile à imaginer, et les explications de nicO sont très claires.
Faut non plus pas prendre le lecteur lambda pour une pomme.
[^] # Re: Commun des mortels ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 10.
Il y a des problèmes dans le branchement du grand oléoduc comme cela avait été prédit. Il faudra le vider quand il y aura autant de vélos que sa longueur.
Ne croyez pas que l'exagération soit outrancière,la réalité dépasse souvent l'imagination.
[^] # Re: Commun des mortels ?
Posté par Anne Onimousse . Évalué à 3.
C'est le genre de truc que l'on apprends lorsque l'on essait d'optimiser du code par exemple pour faire des jeux ou de la 3D ce qui est quand même la principale motivation pour faire de l'assembleur (chez les etudiants tout du moins).
Maitenant pour quelqu'un qui n'a jamais fait d'ASM c'est sur qu'il ne peut pas comprendre.
Mais c'est comme pour tout les articles un peu développeur, si tu ne sait pas programmer en C, malloc() ça peut être du chinois. Si tu ne connais pas TCP/IP un port ou une IP c'est du chinois aussi.
Sinon, pour la phrase, depuis le 486 les processeurs sont pipelinées, c'est à dire que l'on découpe l'éxécution de l'instruction en tranches par exemple pour le 486 : Fetch (lecture), Decode 1, Decode 2, Execution, et Write (ds les registres). L'avantage c'est que l'on gagne en fréquence, car celles-ci sont limités par la latence des porte-logiques, si tu découpe ton processeur en 5 étapes, tu peux espérer utiliser dans chaque étape 5 fois de portes. Comme tu as 5 fois moins de portes, même si la latence de chaque porte est la même qu'avant (parce que tu grave toujours avec le même process, tu n'est pas passé par exemple du 0.18 micron au 0.13), la durée minimale pour que toute les portes aient le temps de basculer est diviser par 5, donc au lieu que la freq maximale de ton processeur soit de 10 Mhz elle passe à 50 Mhz.
Maintenant, l'inconvénient c'est que des fois tu dois vider ton pipeline par exemple parce qu'il y a un saut conditionnel et que ton pipeline il est remplie avec des instructions que tu n'aurais pas executer. Donc tu jette tout, et tu recommence le fetch, le décodage, l'éxécution ... ce qui te fais perdre un nombre de cycle égal au nombre d'étape du pipeline.
Ex : Le pentium 4 a 20 étages dans son pipeline contre 12 pour le PII/PIII donc il atteint des fréquences plus élevés mais comme le cout d'un vidage de pipeline est plus élévé à fréquence égale ses perf sont inférieures à celles d'un PIII (car il passe plus de cycles à ne rien faire).
[^] # Re: Commun des mortels ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
L'athlon utilise 14 niveaux (d'où sa vitesse par rapport au PIII).
On parle là de latence du pipeline entier pour la méoire c'est encore autre chose. Le future bidule de AMD aura une latence de plus de 30 sur le pipeline de la mémoire.
Cela explique aussi que les pénalités de misprédiction peuvent attendre plus que la longueur du pipeline abituellement donné.
nicO
"La première sécurité est la liberté"
[^] # Re: Commun des mortels ?
Posté par Paerro Trime . Évalué à 1.
depuis le 486, les processeurs intel sont pipelinés. Je reconnais que j'ai pas vérifié, mais j'ai du mal à croire qu'ils aient été les premiers à explorer le sujet...
> Ex : Le pentium 4 a 20 étages dans son pipeline
> contre 12 pour le PII/PIII donc il atteint des
> fréquences plus élevés mais comme le cout d'un
> vidage de pipeline est plus élévé à fréquence
> égale ses perf sont inférieures à celles d'un PIII
> (car il passe plus de cycles à ne rien faire).
Ils ont pas aussi dégraissé au niveau unités de calcul ?
# remarque.
Posté par destroy . Évalué à 10.
J'en profite pour exposer ma philosophie...
Je pense que la recherche est actuellement trop basée sur la puissance des proc (attention, il en faut) et pas assez sur l'efficacité des algos....
La j'ai 3 ordis chez moi : 1 486 1 P2 233 et un athlon 1,4 GO....et j'utilise actuellement le 486 qui me sert de terminal du P2 qui exporte son display (l'hiver étant terminé, ca me permet d'éviter la deshidratation dans mon appart)
Et mon P2 marche fort. Comme quoi je trouve des avantages à un P2 (sauf quand le chauffage est en panne)
Je pense qu'il faut aller de l'avant, mais le problème est actuellement que ce serait bien que les chercheurs bossent moins sur des super MACHIN OCTO-truc et que les programmeurs et chercheurs se rappellent leurs cours de génie logiciel en ce qui concerne l'efficacité des algos.
Je trouve anormal que des programmes gaspillent 90% du temps CPU qu'ils demandent.
Conbien de fois voit-on des chercheurs demander un super machin durant des mois alors qu'une semaine d'optimisation de code permettrait d'arriver au même résultat sur les machines qu'ils ont sous la main.
Ceci dit, je ne crache pas sur de telles performances....
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: remarque.
Posté par Alberto . Évalué à 10.
Au contraire, je pense qu'il y a beaucoup a gagner a reflechir au niveau algorithmique. L'algorithmique classique est basee sur le modele RAM qui considere que chaque acces a la memoire est uniforme, or de plus en plus les architectures materielles sont basees sur des hierarchies memoires (registre, caches L1, L2, L3, disque...). Il y a ainsi un fossee entre l'algorithmique classique et le developpement d'application efficace tirant parti du materiel. Certains algorithmes sont mauvais en pratique a cause de ca. !
Juste un exemple pour bien comprendre. Si l'on realise un produit de matrice (C = A x B) avec un algorithme classique (calcul de c_{i,j}) alors pour calculer une ligne de la matrice C, il va falloir acceder a toute la matrice B (qui peut ne pas tenir en L2, ni meme en memoire). On peut alors faire ce produit par bloc mais dans ce cas on ne tire parti que d'un seul niveau de "cache" (souvent le plus petit). Un produit de matrice recursif (il tire partie efficacement de tous le niveaux de cache) est plus adapte, il permet ainsi de realiser efficacement le produit de plusieurs matrices qui ne tiennent pas en memoire central !
(ps: Le produit de matrices est un exemple, il existe des algorihtmes theoriques mieux qu'en o(n^3), la complexite du produit de matrice est meme un pb ouvert ! mais on peut reflechir a des algorithmes pour d'autres problemes)
Pour ce qui est de l'optimisation de code a proprement parler, les compilateurs optimisants pour des architectures actuelles (pas c merde de x86 donc ;-) font mieux que les humains...
Les compilos sont en general bons pour ce qui est de l'optimisation local (au niveau du bloc d'instructions) par contre au niveau global c'est moins fun. Certains arrivent a faire quelques trucs au niveau des boucles pour "vectoriser" un peu le code mais c'est a peu pret tout.
Pour moi, il y a donc de la place en recherche entre la theorie pure et dure (P=NP?) et l'architecture des processeurs. Par contre, il faut bien garder en vue que developper des processeurs rapides permet de gagner sur toutes les applications (sans rien couter au niveau developpement logiciel) alors qu'optimiser un algorithme/ une application est local a l'application donc plus cher. Il convient donc de developper des techniques algorithmiques applicables a un spectre large d'applications.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: remarque.
Posté par Alberto . Évalué à 2.
Non ce dont je parle est a la frontiere entre algorithmique et optimisation. Je ne souhaite pas adapter un algorithme a une architecture particuliere (pex: tunner pour une taille de cache donnee), mais construire des algorithmes efficaces pour une famille large d'architectures (les architectures hierarchiques). Il y a un bon article sur les articles cache oblivious (tirant parti efficacement d'un cache quelque soit sa taille) dans FOCS99.
Il est évident que certains algorithmes marche mieux sur certaines achitectures mais il est plus intéressant de trouver un algorithme qui marche mieux quelque soit l'architecture. Ce qui correspond à un abaissement de la complexité.
Je suis d'accord avec toi ! sauf sur la derniere phrase. Certains algorithmes de meme complexite (o(n^3)) sont efficaces alors que d'autres ne le sont pas. Relit l'exemple du produit de matrice, l'algorithme classique de produit de matrice fait des mauvais acces a la memoire.
Lorsque tu parles de complexite en o(x) tu supposes en general implicitement un modele de type ram (random access memory) et tu supposes implicitement egalement que les temps d'acces memoire sont identiques. Ces hypotheses sont insuffisantes pour avoir une corollation forte entre complexite et efficacite.
>la complexite du produit de matrice est meme un pb ouvert
Ca m'étonnerai beaucoup qu'on fasse mieux que le nombre d'éléments de la matrice à calculer (n²) à moins de pouvoir tout faire en parallèle (turing vs ...).
Oui cette borne inferieure du produit de matrice est triviale, mais malheureusement aucun n'algorithme de produit de matrice en o(n^2) n'a ete trouve ! Il existe par contre des algos en o(n^k) avec 2<k<3. Je repete la complexite du produit de matrice est un probleme ouvert.
Au niveau des optimisations des compilos je corrige un peu ce que j'ai dit il y a beaucoup d'optimisations au niveau de la fonction (j'avais dit bloc d'instructions) c'est quand meme assez local et j'ai dit que les compilos etaient bons au niveau local (les optimisations classiques dont tu parles sont surtout locales). Qaunt'aux optimisations sur les boucles (autres que l'unrolling mais plutot recherche de localite dans les boucles tilling & co), c'est toujours un sujet de recherche actif.
[^] # Re: remarque.
Posté par Merlin Lenchanteur . Évalué à 10.
> Je pense que la recherche est actuellement trop basée sur la puissance des proc (attention, il en faut) et pas assez sur l'efficacité des algos...
Mais le probleme c est qu un bataillon d ingenieurs pour optimiser les codes ca coute la peau des couilles (ca tu le savais deja)
en tout cas plus cher que changer des machines regulierement et en plus ca fait marcher l industrie
C est pas pour t inqueter mais cette tendance va encore largement s amplifier puisque suite au 11 septembre les EU ont transferes beaucoups de credits sur l armee, et c est ce genre de recherche qui donnent des coups de fouets a l electronique.
Lors d une prochaine crise lorsque l industrie et la recherche pietinneront dans la course a la puissance peut etre que cette tendance s inversera mais a mon avis c est pas pour tout de suite...
[^] # Re: remarque.
Posté par jigso . Évalué à -3.
(Au cas où ta touche ['] est bloquée... ;-) )
[^] # Re: remarque.
Posté par Babou . Évalué à 10.
NB: quand je dis 60% de puissance de crête, aucun rapport quand avec top, vous voyez votre processeur à 0% d'idle.
re-NB: qu'est-ce qu'un noeud pour ceux que j'ai perdu en cours de route ? Et bien pour parler simplement, une carte mère avec de 1 à 16 processeurs grand max (couramment 4 ou 8 sur les gros calculateurs type SP3). Donc en réunissant tous les noeuds, on a nettement plus de mémoire, mais par noeud, on a toujours pas assez. Pourquoi pas plus de processeur par noeud ? Problème d'architecture, de bus mémoire, de cache, de ... c'est un tout. Et pas un simple.
[^] # Pas d'accord
Posté par Moby-Dik . Évalué à 10.
Pour ce qui est des quelques algorithmes effectivement mis en jeu de façon routinière dans un ordinateur, je pense au contraire qu'ils sont pas mal optimisés. Il suffit de voir tous les encodeurs audio ou vidéo écrits spécifiquement pour exploiter le SSE d'Intel par exemple ; ou les récents changements dans le scheduler Linux (passage en O(1)). Mais, sauf utilisation méchamment spécialisée (lancer un batch de ray-tracing par exemple), ce type d'optimisations algorithmiques ne peut concerner qu'une partie de plus en plus réduite du code exécuté par une machine de bureau.
[^] # Re: Chacun sa specialite
Posté par a_jr . Évalué à 10.
Y'a des gens qui sont bons en recherche de perfs de processeurs et d'electronique en general, et y'a des gens qui sont bons en optimisation d'algo. Chacun son truc et c'est pas la peine de demander a quelqu'un qui bosse sur un processeur d'optimiser un logiciel usine a gaz.
Mais ce serait effectivement pas mal que les gens qui distribuent les credits en donnent un peu plus pour l'optimisation logicielle.
Et sans meme parler de credits, si les programmeurs pouvaient faire un effort d'optimisation plutot que de dire que de toute facon, ca tournera bien sur un PC a 2 GHz!
Rappelons que Cavedog avait fait un excellent jeu Total Annihilation (http://www.totalannihilation.com/(...)), qui etait assez lent mais ca allait encore, et qui a coule apres avoir sorti la suite, TA Kingdoms, qui la ramait vraiment trop. S'ils avaient tire profit du hardware existant et non pas du hardware futur, et s'ils avaient optimise...
Le bonjour chez vous,
Yves
[^] # Re: Chacun sa specialite
Posté par Boa Treize (site web personnel) . Évalué à 10.
> gens qui distribuent les credits en donnent un
> peu plus pour l'optimisation logicielle.
Euh, on appelle ça des clients, non ? Vous semblez oublier qu'une grosse partie de l'industrie informatique vit en vendant des logiciels, et que pour survivre dans ce milieu, comme dans tout autre, il faut trouver un équilibre entre l'investissement financier et la qualité que l'on souhaite voir dans le produit et le coût que l'on devra répercuter à l'utilisateur.
> si les programmeurs pouvaient faire un effort
> d'optimisation plutot que de dire que de toute
> facon, ca tournera bien sur un PC a 2 GHz!
Les programmeurs, ils font un énorme effort pour finir leur tâche en temps et heure. Si leur métier est de passer du temps à optimiser un algo, parce qu'il a été décidé que ce point précis de l'application n'était pas assez performant, alors ils y passent du temps. Sinon, il serait plutôt mal vu (et pas très intelligent) de passer des heures à optimiser son coin de programme. Une optimisation se décide au vu des statistiques d'exécution d'un programme, qui permettent d'identifier dans quels modules (classes, fonctions, etc.) se trouvent les problèmes de performance.
> S'ils avaient tire profit du hardware existant
> et non pas du hardware futur, et s'ils avaient
> optimise...
Ils n'auraient jamais sorti TA à temps.
[^] # Re: Chacun sa specialite
Posté par Croweye . Évalué à 3.
ça, c'est vraiment du foutage de gueule ou de l'incompétence pure et simple
[^] # Re: Chacun sa specialite
Posté par a_jr . Évalué à 4.
C'est un peu nul, mais c'est comme ca.
Le bonjour chez vous,
Yves
[^] # Re: remarque.
Posté par Boa Treize (site web personnel) . Évalué à 10.
> basée sur la puissance des proc (attention, il
> en faut) et pas assez sur l'efficacité des algos....
Je ne suis pas du tout sûr qu'en transférant l'argent consacré à la recherche sur les CPU à la recherche algorithmique, on obtienne un doublement des performances tous les dix-huit mois (ou à peu près). Les algos efficaces, on les connaît déjà, pour la plupart. La lenteur perçue des systèmes d'exploitation actuels tient plus à des problèmes de performance d'entrée/sortie, la lourdeur des interfaces graphiques étant sans cesse croissante, et à l'architecture d'un niveau d'abstraction croissant, ainsi qu'à l'emploi de technologies de plus en plus éloignées du matériel (machines virtuelles, XML, etc.) qui, si elles présentent des avantages indéniables, n'en entraînent pas moins une lourdeur assez gênante sur une machine personnelle.
> mais le problème est actuellement que ce serait
> bien que les chercheurs bossent moins sur des
> super MACHIN OCTO-truc
Pas de problème. Achetez 50,1% d'IBM, et voilà, vous pouvez imposer votre décision. Vous semblez perdre complètement de vue que pour l'essentiel dans le matériel informatique et électronique, la recherche est effectuée par des entreprises dont l'objectif est de fabriquer des produits plus performants et à moindre coût. Il se trouve qu'il est infiniment plus rentable d'accroître la puissance de calcul disponible (+100% en 18 mois ?) que de "perdre" son temps à optimiser (+10% en deux ans ?).
> et que les programmeurs et chercheurs se
> rappellent leurs cours de génie logiciel en ce
> qui concerne l'efficacité des algos.
Vous parlez de qui, là ? Les gens qui créent des processeurs, des compilateurs et des systèmes d'exploitation sont dans leur immense majorité extrêmement compétents et connaissent l'algorithmie sur le bout des doigts... entre autres. Ne les confondez pas avec la chair à canon que vous a refilé la SSII du quartier, et qui aurait peut-être bien besoin d'un rafraîchissement à ce niveau. Pour votre information, lors de la journée d'entretien d'embauche chez Microsoft, de très nombreuses heures sont consacrées à démontrer sa compétence en problèmes logiques et algorithmiques. Les problèmes de performance sur les systèmes modernes ne viennent pas tant de problèmes algorithmiques, mais sont plutôt liés à des choix architecturaux, qui peuvent être très lourds (encore une fois, VM, XML, etc.)
> Je trouve anormal que des programmes gaspillent
> 90% du temps CPU qu'ils demandent.
Vous mesurez ça comment ?
> Conbien de fois voit-on des chercheurs demander
> un super machin durant des mois alors qu'une
> semaine d'optimisation de code permettrait
> d'arriver au même résultat sur les machines
> qu'ils ont sous la main.
Euh, jamais ? C'est une grosse affirmation un peu violente que vous faîtes là, et ce serait sympa de citer des exemples.
[^] # Re: remarque.
Posté par Emmanuel Collet . Évalué à -1.
Sinon, our une utilisation plus "pro", sa me fait alluciné qu'au boulot on lance des calcues sur des alpha seveur de ouf , et qui n'utilisent q'un seul processeur, ou bien qu'un seul alpha-seveur (on a à 2 en cluster), ou encore qui n'utilisent pas non plus les 10 stations alpha pas mal tout de meme dispo...
[^] # Re: remarque.
Posté par a_jr . Évalué à 4.
Ils sont combien?
On parle plutot des gens qui font les programmes pour le grand public.
Ne les confondez pas avec la chair à canon que vous a refilé la SSII du quartier
Des noms? Y'a SSII et SSII. D'autre part, sans parler de SSII, je vais te citer un cas puisque tu demandes des citations.
Jamais, dans les codes que j'ai lu en entreprise je n'ai vu de code de tri optimise. C'est toujours le tri a bulle qui est utilise. Pourtant, si on ne veut pas se casser la tete, y'a "man qsort". Et si on veut vraiment se la casser, y'a d'autres algos, dont un qui est base sur le tri a bulle mais qui est plutot efficace.
Et le tri n'est surement pas le seul exemple.
Le bonjour chez vous,
Yves
[^] # Re: remarque.
Posté par Babou . Évalué à 8.
Tu y vas un peu fort avec tes 10%. Dans le domaine du calcul scientifique, il faut savoir que l'essentiel du code est écrit par des non-informaticiens (physiciens, météorologues, chimistes ...) qui n'ont pas souvent connaissance des techniques et technologies utilisables (par exemple les BLAS avec lesquels on peut réduire par 10 ou plus des temps d'exécution). Il y a effectivement des codes bien difficiles à améliorer pour un gain faible, mais il existe encore bon nombre de codes donc les performances restent faibles, par méconnaissance des outils, ce qu'on ne peut pas reprocher à des non-parallélistes, ce n'est pas leur job. Et vu le gain qu'on peut avoir en ayant cette connaissance, reconnaît que ça vaut la peine de s'y intéresser de très près.
[^] # Re: remarque.
Posté par destroy . Évalué à 1.
[^] # Re: remarque.
Posté par Dugland Bob . Évalué à 1.
Le problème de ces langages, est qu'ils sont bas niveau : quand tu tapes, à peu de choses près, tu connais l'implantation assembleur sous-jacante. Et ils sont difficilement optimisables (voir pas ex. la doc du compilo Intel sur la vectorisation).
Foutre toute la recherche actuelle (+ crédits + formation des générations futures) sur des langages de haut niveau (en particulier les compilos) serait largement bénéfique.
Pour rappel, O'caml est en passe de rattraper le C sur des truc bourrins car il est optimisable.
Un exemple de ce laxisme : je suis obligé d'apprendre par moi-même les langages fonctionnels, la sémantique des langages etc. Alors que je suis en IUP Info.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.