Reprise du message précédent :
il sont même pas d'AMD zone les benchs :
http://www.pcworld.com/news/articl [...] g,8,00.asp
 

 
7,8 GFlops pour un G5 à 1,8GHz ???
Ca veut dire qu'il est capable de faire 5 opérations à virgule flottante par cycle....  
 
... bonne blague  

Les gens ne biaisent pas les résultats de benches, ils prennent simplement tel ou tel type de bench qui favoriseront une plate-forme ou l'autre selon ce qu'il veulent démontrer. Le résultat sera exact en lui-même bien que pas représentatif.
On peut trouver des tests où mon P4 ridiculiserait ton Mac et d'autres où ma lessiveuse n'existerait même pas face à la tienne, sans biaiser quoi que ce soit  
C'est un peu ce que chris13 a fait en "oubliant" de préciser que seti a une verson graphique et une version texte nettement plus rapide. Pratique pour enfoncer le plate-forme adverse...
 
L'histoire de l'allocation de mémoire sur le Mac était vraiment une tare, jamais compris pourquoi ça a perduré si longtemps.

oui deltaten 7,8Gflops sur mon G5 1,8Ghz parfaitement.
 
Pour rappel tout processeur RISC fait au pire 1 opération flottante par cycle (ce que fait au mieux un proc CISC sisi)
 
non non ce n'est pas une bonne blague
 
http://www-3.ibm.com/chips/product [...] ocus2.html
 
Regarde ce lien c'est marrant mais 5 instructions per cycles en flottant c'est justement ce que fait ce PPC970(et regarde la date decembre 2002 désolé pas de polémique avec Apple)
 
Tiens regarde ça aussi si tu veux:
 
http://www.pcinpact.com/actu/news/ [...] =1#c104546
 
et ça:
 
http://www.tombridge.com/rta/2003/ [...] te__1.html

ces fameuses 5 instructions par cycle c'est à cause d'un beau petit système sur le POWER4 (dont le G5 dérive pour rappel)

impressionant
 
Mais il s'agit de 4 instructions FPU par cycle, pas 5 !
Il y a deux unités FPU qui peuvent chacune faire un FADD et un FMUL par cycle. ça donne bien 4 Flops/cycle.
 
Les 5 instructions par cycle dont ils parlent c'est dans le dispatcher, pas dans les unités d'exécution.
 
Donc ça fait bien le double du K8, qui  peut faire un FADD et un FMULT par cycle (plus un FLOAD/STORE)
 
Par contre en simple précision et en vectoriel (avec ALTIVEC), le PPC970 est capable de faire 8 opérations par cycle ! Mais bon, c'est surtout la double précision qui est intéressante pour les calculs scientifiques. Et là, ça reste 4Flops/cycle, avec ou sans Altivec.

Xbench donne des Gflops en single précision en 32 bits ce sont des "détails" qui ont leurs importance
 
Tu vois par exemple un proc comme le POWER4 est conçu pour traiter des données en continu à une cadence infernale
pourtant d'aprés IBM eux même Un G5 sur le benchmark (heu je sais plus lequel) donne plus de Gflops qu'un POWER4
Est -ce que le POWER4 est moins puissant pour autant?
Bien sûr que non!
vu que le G5 est monocore bien qu'à une fréquence supérieure t'es tranquille qu'il est au moins 2 fois moins puissant et je suis extrêmement gentils avec le G5 (en gros je pense qu'un G5 doit faire quatre fois moins en fait)
 
Le POWER4 peut grâce à ces 32Mo de L3 traiter des gros "volumes""grosses applis" bien plus vite que le G5(comme chacun sait un programme n'est jamais aussi rapide que lorsqu'il s'éxecute dans la cache L1)
 
Le G5 il lui faudra pêcher dans sa mémoire vive et là si tu testes les deux procs  
t'arriveras pas vraiment à la même conclusion!
 
regardes ce PDF
http://www-3.ibm.com/chips/techlib [...] 5200611780
 
Tu y verra le G5 soit disant plus rapide que le POWER4

curieux quand même ces benchs G5>POWER4 mais G5 version dégonflée du POWER4?   AH lala les Benchs........

Tenez justement Blazkowicz donne le test de PCworld relayé par AmdZone à un moment ou je le rappelle je doute qu'ils aient pu se fournir des powermacs G5 qui étaient bel et bien indisponibles à ce moment.
 
Ce test publié même si il a été réalisé est nul et non avenu pour ce qui est de tester la puissance processeur et cela est trés facil à montrer:
 
-Regardez attentivement les configurations proposées
Le raid risque d'aider un petit peu non parfois?
-les tests sous world? bizzare non vous croyez que crosoft a mega optimiser world en le portant sur mac pour gagner 0,0000000000001 seconde sur les tâches? très sérieux de tester sur world c'est assez pathetique
-Regardez attentivement quelles cartes vidéo possèdent les différentes config
non vous ne pensez pas que ça a son importance sur Quake3?
-certains logiciels comme premier qui tourne en EMULATION MACOS CLASSIC  
-Quake3 tourne bien évidement dans sa version non optimisé altivec et même peut être en émulation mais bon...
Je ne vais pas aller plus loin mais ce test est facil à décortiquer et à enfoncer et à ranger Dans la trés belle collection des tests foireux tout comme les test d'Apple d'ailleurs.
 
Touts ces tests ont déjà été assez bien décortiqués de nombreuses fois sur le net et il est clair qu'ils sont complètement biaisés et cela de façon totalement intentionnel.

A+

• la mémoire ECC n'améliore en rien les perfs de calcul pur, c'est surtout valable pour les serveurs dont le service doit être ininterrompu
• photoshop est tout simplement optimisé SSE2, je ne pense pas qu'il soit optimisé Altivec, sinon çà dépoterait

un petit article simpa sur le G5
http://arstechnica.com/cpu/02q2/ppc970/ppc970-1.html

josedsf j'ai survolé cet article et le problème c'est que je comprends rien je suis nul en anglais et ça aide pas mais merci quand même pour ton lien.

Bon bé pour résumer le G5 est conçut pour les hautes fréq mais sans pousser le bouchon aussi loin que le p4 qui reste le seul par exemple à présenter des étages du pipeline qui ne font rien, à part transmettre le signal, signe qu'Intel se sert de la fréq plutot que des perfs pour "vendre" ses CPU.
 
Le G5 est aussi un cpu très parrallèlisé (beaucoup d'unités d'exécutions) contrairement au p4 qui se présente comme un cpu en série. Ceci favorise (avec la faible consommation) le G5 en SMP.
 
Le G5 possède aussi la particularité de grouper les micro opérations avant traitement par 5 selon des règles précises, afin de retrouver ses petits (vu que 200 micro op peuvent être simulatnément en cours d'exécution à différents stades, à comparer aux 128 du p4).
Ceci présente des avantages, et aussi des inconvénients : quand les règles de "groupage" ne sont pas respectées, le cpu n'envoie rien dans son pipeline et on perd un peu en efficacité.
 
Enfin le G5 est 64bits.
 
Bref l'objectif d'IBM est clair :  
 

• fournir Apple avec un cpu multimédia (unitée Altivec sensée être plus puissante que le SSE2, hautes fréquences...)
• concurrencer les Xeons et Opteron en SMP
• rentabiliser les couts de développement du POWER4

voilà ce dont je me souviens des mes lectures ici et là, mais n'oublies pas que les Mac sont bien plus chers que les PC

Et pourquoi tu ne l'as pas dit directement. Quand on parle de Gflops, c'est en 64bits que c'est intéressant d'en parler, pas 32bits. Il faut comparer des choses comparables...
 

n'importe quoi...
Ces deux CPU sont basés sur la même architecture. Le dual-core du Power4+ n'augmente les perfs que si l'appli est faite pour utiliser deux CPU. C'est exactement comme un système SMP. Ce n'est pas ça qui multiplie la puissance par 2...
 
Vu que le G5 a une fréquence supérieure, tous les benchs/applis qui tiennent dans le L2 du G5 sont plus rapides sur G5 que sur Power4. C'est tout à fait normal.
 
 
 

encore heureux que le G5 est meilleur, ils comparent un Power4+ à 1GHz à un G5 à 1,8Ghz.    
Mais tu n'a pas du bien lire, car le bench montre aussi qu'un G5 1GHz est battu par un Power4 à 1GHz...

et si il y a corruption de certains résultats de calcul ?
Toute la simu est faussée, et il n'y a strictement rien qui puisse le détecter et encore moins le corriger. C'est ça qu'il veut dire par "donc vaut mieux pas faire des calculs trop sérieux"
 
Regarde un peu le bazar que ça a fait quand Intel s'est rendu compte d'un bug de calcul dans l'Itanium...
 

   
Le fait que ce soit un CPU fort parallélisé favorise le G5 en SMP ? Pour quelle raison ?
 

Disons que l'implémentation de l'Altivec des G5 en fait une unité plus puissante que l'implémentation actuelle du SSE(2) dans les K8/P4. Rien n'empèche dans le futur d'avoir un K9 capable d'effectuer 4 opérations FP 64bits en SSE2 comme le G5.
 
Il y a peut-être un des jeux d'instructions qui est meilleur que l'autre, mais ça faudrait se renseigner plus en détail.  

savez-vous pourquoi MOTOROLA a inclu l'altivec dans le G4?
 
Pour cisco système.
 
Je m'explique, altivec a à la base pour but de faire du cryptage/décryptage 72bits dans des bécannes de cisco système
 
C'est une unité à 128bits vectorielle très puissante mais elle demande une optimisation soignée pour tirer le meilleur partis de cette puissance très spécifique à la base pour en quelque sorte la reçycler pour du tout venant
 
Ainsi,en puissance brute il ne fait aucun doute que l'unité altivec est plus puissante que le SSE2(même beaucoup plus) mais bien plus difficil à utiliser pour un développeur  
donc l'un dans l'autre les puissances développées par ces deux unités sont variables selon les logiciel et même très variable pour l'altivec ce qui fait qu'il est difficil de dire quelle est la mieux

Deltaten les deux cores du POWER4 sont bel et bien utilisés justement l'intêrêt du multicore est entre autre de ne pas avoir à optimiser le logiciel
 
je m'explique contrairement à du multiprocessing ou chaque puce a son contrôleur une puce multicore a un contrôleur unique répartissant les tâches entre les cores les mémoire cache sont uniques également dès lors le logiciel ne voit qu'un seul controleur donc qu'une seule puce.
Ainsi le PPC970 n'a pas le même controleur que le POWER4 et ce contrôleur a été conçu tout ou partie par Apple car le contrôleur définie l'interface entre les logiciels et les unités d'éxecution.  
 
Le PPC 970 à 1Ghz n'existe pas le POWER4 à 2Ghz n'existe pas  
et un POWER4 à 1Ghz est de toute façon plus puissant qu'un G5 à 2Ghz  
 
Pour le Xbench je dit 32bits parceque le proc est exploité en 32bits pas parceque les instructions envoyées sont en 32bits
Deltaten a écrit:
 
vu que le G5 a une fréquence supérieure, tous les benchs/applis qui tiennent dans le L2 du G5 sont plus rapides sur G5 que sur Power4. C'est tout à fait normal.  
 
T'es sûr la cache L2 du POWER4 est à 1,5Mo et elle est bien plus rapide que celle du G5(rapidité n'est pas fréquence)
 

Il est clair qu'au niveau implémentation, la meilleure actuellement est l'Altivec du G5.
 
Ma question était de savoir quel jeux d'instructions (Altivec ou SSE(2)) est intrinsèquement meilleur, s'il y en a un meilleur que l'autre. Cela, sans parler des implémentations faites dans le G5 et dans les K8/P4 respectivement.

non

 
Absolument pas...
 
Déjà, je n'ai aucune idée de ce que tu appelles controlleur...
Je supposes que tu parles des unités de décodage/sheduler... qui a au début du pipeline du CPU ? Si c'est ça, tu as une très mauvaise vision de ce qu'est un processeur multicore.
 
Un CPU multicore est EXACTEMENT comme du multiprocessing. Tu prends un CPU et tu fais un copier-coller du core juste à coté, sur la même tranche de Si. Le seul truc qui est partagé, c'est l'interface vers le monde extérieur. Et parfois le cache L2 comme sur le Power4. Mais pas toujours (les prochains SPARC dual-core et les K8 dual-core auront des caches L2 séparées).
 
De plus Apple n'a strictement rien touché au CPU même.
 
Ou alors tu parles du controlleur sur la carte-mère (~= northbridge) ?  
Si tu parles de ça, ça n'a pas plus de sens car cet élément n'a strictement aucun rôle dans une prétendue interface entre le logiciel et le(s) CPU(s).
 
Quand on a un CPU dual-core, on a excatement la même chose qu'un système bi-CPU, sauf que le lien entre les deux CPU est extrèmement rapide.
 
 

et la marmotte elle emballe le chocolat...  
C'est tellement dépendant de l'application, que cette phrase n'a pas beaucoup de sens. Mais en règle générale, c'est très loin de la vérité.
 

bon alors, c'est en simple (32bits) ou en double (64bits) précision que c'est réalisé ton test ? Je parle pas du mode dans lequel tourne ton CPU (et donc l'OS), mais de la taille des flottants avec lesquels le bench travaille (qui n'a rien a voir avec le mode de fonctionnement: les CPU x86 sont capables de faire des calculs sur des flottants 80bits depuis l'époque des 286).
 
 

la cache du Power4 est plus rapide, t'es certain ?
Alors ça peut jouer oui, mais le G5 tourne à une fréquence plus élevée...

   bon d'accord alors un G5 est un power4 dégonflé qui côute à peu prés 10 fois moins cher et qui est plus puissant quelle merde ce POWER4 alors (je te charie un peu)
 
Oui parfaitement la cache L2 du POWER est bien plus rapide et beaucoup plus chère également les 32 Mo de cache L3 ne sont pas données non plus dans le genre.
Deltaten a écrit:
Un CPU multicore est EXACTEMENT comme du multiprocessing. Tu prends un CPU et tu fais un copier-coller du core juste à coté, sur la même tranche de Si. Le seul truc qui est partagé, c'est l'interface vers le monde extérieur. Et parfois le cache L2 comme sur le Power4. Mais pas toujours (les prochains SPARC dual-core et les K8 dual-core auront des caches L2 séparées).  
 
Bon alors explique moi un peu l'avantage du multicore sur le multiproc parceque là si c'est pas plus puissant je sèche
 
Le contrôlleur est interne au processeur c'est lui qui réparti le travail entre les différentes unités (et core) d'éxecution
 
c'est lui qui organise le travail et si il est mal fait même avec un core top de bloc derrière ton proc sera une grosse merde
le contrôleur travaille en lui même il est comparable à la coulée de substance réticullée de la protubérance cérebralle(heu merde je délire encore...)
 
Il ne fait pas que dispathcher les infos il les trie les ordonne et les réparti et c'est pour cela que le contrôlleur du G5 n'est pas le même que celui du POWER il n'a qu'un core et deux unités altivec en plus et si Apple a bien participé à la conception du contrôlleur du G5 et c'est là d'ailleurs sa seule participation.
Le contrôlleur du proc c'est son noyau le reste ne fait que lui obéir.
 
Bon je vais être franc,je vais téléphonner à mon Brother qui connais ça très bien et de manière fiable puisqu'il est en école d'ingé informaticien et qu'il bosse à la conception d'un proc actuellement.
 
 
 
 
 

le multicore c bien.. parce que tu as deux CPU sur une puce au lieu d'un seul
c'est un peu mieux que le multi-proc classique (pentium pro, xeon, athlon MP..) ou les deux procs se partagent le FSB
 
mais les deux cores se partagent qd meme le meme controlleur memoire
 
le multi proc de type opteron est mieux car la bande passante est doublee quand on double le nombre de CPU, alors qu'elle ne bouge pas dans le cas du multicore

Il y a d'autres grosses différences en plus du dual-core et du L3.
Le schéma du Power4+ est un peu plus rempli que celui d'un PPC970...
http://www.research.ibm.com/journal/rd/461/tendl1.gif
 
C'est surtout énormément de système de communication pour, à partir de cartouche contenants 4 chips (et donc 8 CPUs),
http://www.research.ibm.com/journal/rd/461/tendl9.gif
 
réaliser des systèmes contenants des dizaines de CPUs (32 dans le schéma):
http://www.research.ibm.com/journal/rd/461/tendl10.gif
 
 
Va-y un peu pour faire un système 32 CPU efficace à partir de G5
 

ça permet:
- de réduire la latence et augmenter le débit de comm entre deux CPUs
- de diminuer le prix d'un système SMP au niveau de la carte-mère: on peut avoir deux CPUs en ayant un seul slot, un seul FSB...
- un système bi-CPU peut devenir quadri-CPU avec peu de changements
- il y en a sans doute d'autres ??
 
 

j'aimerais bien que tu me dises ce que tu appelles "controlleur" sur le schéma ci-dessous. (c'est un K8):
 

 

ok, fait comme tu le sens
C'est bizarre qu'un étudiant-ingénieur en info fasse ça mais bon...
 
Edit: en fait, non, c'est pas tellement bizarre, il y a parfois des infos qui ont des cours d'elec avec nous dans notre fac. Le problème, c'est surtout s'il faut parler des technologies d'implémentation/fabrication, là ils ont plus de mal.

Bon, alors inutil de compliquer les choses la différence entre multicore et multipro est assez facile à expliquer:
 
Commençons par des définitions:
 
-Un CPU n'est pas un microprocesseur  
-Un CPU est l'ensemble des unités d'éxécution (en gros ce ne sont que des ensembles de porte logiques).
-Un microprocesseur est constitué en gros de deux choses:
CPU+MMU=microprocesseur
-MMU=contrôleur
 
 
Maintenant,comment fonctionne un programme?
-Un programme ne voit que de la mèmoire virtuelle il "envoie" ses instructions avec des adresses mémoire virtuelle (4Go sur une puce 32bits et ce même si il y a moins en mémoire physique)
 
Un petit grains de sable transforme les adresses mémoire virtuelles en adresses physiques donc sur la mémoire vive les instructions s'enregistrent sur leurs adresses physiques dans la mémoire vive (d'ou une communication entre Disque dur et mémoire vive).
 
-Ensuite,la MMU (qui est sur le silicium sur le processeur) lit les instructions dans la mémoire vive et c'est elle qui déduit quelles sont les instructions à effectuer ,celles à effectuer elle les envoie au CPU
 
-Le CPU les éxécute ,la MMU récupère le résultat du "calcul" déduit ce qu'il faut envoyer à la mémoire vive et renvoie des "infos" à la mémoire vive infos qui sont donc enregistrées dans la mémoire vive.
 
Imaginons un système multiprocesseur
 
et bien alors deux MMU lisent les mêmes instructions dans la mémoire vive et donnent les mêmes instructions à effectuer à leurs deux CPU respectifs
Alors blème le travail est fait deux fois au lieux d'être divisé en deux.
 
Maintenant un système multicore:
 
exemple POWER4=MMU+CPU+CPU
 
La MMU lit les instructions dans la mémoire vive de la même façon qu'une puce monocore (core=CPU le core n'est pas un microprocesseur) d'un système uniprocesseur,simplement la MMU du POWER4 est conçue comme si "Elle traitait 64 unités d'éxécution au lieu de 32 unités" (Un PPC possède 32 unités d'éxécutions ou 64 enfin je sais plus je crois que c'est 32 en entier et 32 en flottant peu importe) C'est pour cela en partie que le contrôlleur du G5 n'est pas le même que celui du POWER4 mais le CPU si.
 
 
 
 
           

si s'est ton frère qui est étudiant ingénieur qui t'as raconté ça, alors:
- soit tu as mal compris ce qu'il t'as dit
- soit il a mal compris son prof
- soit il est vraiment dans la merde...
 
 
Je suis un peu crevé là et j'ai pas trop envie de corriger ce qui est faux dans ce que t'as écrit. Je laisse tomber.
 
Je te conseille de trouver un bon article sur le fonctionnement des CPU, et de repartir des bases, tu y verras plus clair...
 
A+

t'as des drôles d'idées un programme pour toi ça fonctionne comment?
Tu sais ce que c'est l'assembleur?  
Mon frère a étudier le proc 68000 ainsi que l'assembleur 68000
Bon voilà la doc technique du POWER4:
 
http://www-1.ibm.com/servers/eserv [...] itepapers/
power4.html
 
Si tu comprends quelque chose tant mieux pour toi moi de toute façon je peux rien comprendre c'est tout en Anglais mais y'a quelques schèmas.
 
Bon sinon c'est une explication la plus simple possible que j'ai rédigé plus haut sous les directives de mon brother au téléphone  ben si il dit n'importe quoi moi je sais pas mais j'ai plus confiance en lui qu'en un article d'un site internet quelconque sur les proc sinon moi même  ce que je connaît des proc cela me vient surtout de l'ençyclopédie universalis mais faudrait bien que je la relise ça fait un bail la derniere fois que je l'ai regardé (mais bon y'a quand même 300 pages et c'est pas toujours simpliste)
 
t'es difficil à convaincre qu'un G5 se fait laminer par un POWER4 tant pis bon ben A+

ya pas de MMU sur un 68000 non?

T'en fais pas pour moi...
Si tu veux je peux t'expliquer globalement comment marche une CPU depuis ce qui est vu par le software jusqu'aux équations de mécanique quantique permettant d'expliquer le courant dans un transistor MOS, en passant par le niveau circuit, portes logiques et transistors. (et je peux te l'expliquer en détail pour les parties bas-niveau)
 
Evidement, au niveau circuit, je n'ai jamais travaillé sur un truc aussi gros. Mais j'ai déjà implémenté en VHDL (environ au niveau portes logiques) un microcontrolleur basique avec ALU, registres, bus d'entrées/sorties, RAM et décodeur d'instructions ASM (des trucs simples, add/jump/move/conditions simples...).
 
Pour ce qui est de l'assembleur, je sais bien ce que c'est: pour le moment, on doit programmer un PIC dans ce langage pour notre projet (un système de terminal pour cartes banquaires, avec crypto, modem...). Je sais bien qu'un PIC a moins d'instructions qu'un CPU, mais bon, le principe est le même
 

Je ne prétends pas que ton frère dit n'importe quoi, les concepts dont tu parles sont bien présents dans un CPU. Mais à mon avis, t'as un peu mélangé vu qu'il t'as dit ça en vitesse au téléphone.
 
C'est dommage que tu parles pas un peu anglais, il y a des articles pas mal sur le net. Le mieux serait évidement de trouver un cours complet sur l'architecture des ordis, mais j'en ai jamais vu en ligne
 
 

parce que je pense pas que ce soit une vérité pure et dure.
Evidement, sur des grosses taches où on a besoin de travailler sur beaucoup de données le POWER4+ est bien meilleur. Evidement qu'il est bien meilleur si le programme est conçu pour le SMP.
 
Mais pour des programmes plus petits, tournants sur dans la cache du G5, il ne doit pas y avoir une grosse différence au niveau de la puissance à fréquence égale. Mais vu que le G5 existe en 2Ghz et le POWER4 s'arrête à 1,7GHz; le premier est meilleur pour ces tâches-là.

MMU = Memory Management Unit : c'est uniquement l'unité qui sert à gérer les accès mémoire. Elle sert entre autre à convertir les addresses logiques utilisées à l'intérieur des programmes en adresses physiques utilisées pour accéder aux barettes mémoire; comme tu en parles par la suite.
 
Mais je suis quasiment certain que le terme CPU désigne habituellement tout le microprocesseur, et pas seulement l'ensemble des unités d'exécutions. Tout fait partie d'un bloc qui n'est pas vraiment séparable et qu'on appelle CPU. Enfin bon, ce n'est qu'un problème de terminologie.
 

D'accord pour le principe, sauf que ce n'est pas le MMU qui s'occupe de cela.
 
En gros, un CPU schématique est basé sur ce qu'on appelle une machine de Gluskov qui est composée de deux structures :
- une partie opérative : c'est elle qui travaille réellement sur les données, elle effectue des opérations.
- une partie contrôle : en fonction de différentes informations reçues de l'extérieur et de la partie opérative, elle donne des ordres à cette dernière.
 
Bon, voyons comment cela est implémenté dans un microprocesseur, il y a essentiellement 4 parties :

 
- la partie opérative comprend 3 éléments : les différentes unités d'exécution (ALU ici), de quoi stocker les données sur lesquelles on travaille (registres), des ports d'entré/sortie.
 
- la partie contrôle comprend 2 éléments importants : le "Program counter" (PC) est le registre contenant l'adresse de l'instruction qui devra être exécutée après celle en cours d'exécution. L'Instruction Register (IR) contient l'instruction en cours d'exécution. Je parle bien d'une instruction Assembleur (ASM) ici, que le programmeur a encodé (ou généré par le compileur).
 
 
Bon, le controlleur charge un instruction de la mémoire dans le registre IR (à partir de l'adresse située dans PC) et PC est incrémenté de 1. Ensuite, il doit la décoder et exécuter l'instruction. Typiquement, une instruction va demander plusieurs opérations de la part de la partie opérative. Le controlleur décompose pour cela l'instruction ASM en micro-instructions (µ-ops) qu'elle va faire exécuter par la partie opérative l'une après l'autre. Le controlleur a donc un registre de µops qui lui permet de savoir où il en est de l'exécution de l'instruction ASM.  
 
Une fois que cette instruction est exécutée, le controlleur va chercher en RAM l'instruction pointée par l'adresse située dans le PC, et continue donc l'exécution du programme.
 
Un tel µprocesseur simple est présenté dans le schéma suivant:

 
On voit bien les différents éléments (les pointillés séparent le µProc à doite de l'extérieur à gauche): l'ALU qui fait les opérations, les registres IR et PC, le registre MA qui sert juste à pointer des adresses mémoire de données à aller chercher, la RAM (et pas ROM comme il est écrit, c'est une erreur), deux registres de travail accessibles par le programmeur (A et X) et un registre caché au programmeur (S) qui est utilisé comme "mémoire cache".
 
En dessous, on voit la partie contrôle, qui comprent son registre de µ-ops et des entrées (IR et des flags, donnants l'état de l'ALU et le résultat de comparaison pour les instructions conditionnelles) et on voit des sorties de contrôle qui sont envoyées vers la partie opérative au dessus.
 
 
Bon, pour un CPU de PC, c'est évidement autrement plus compliqué.
L'idée de base est toujours la même, mais ici, on effectue beaucoup d'opérations à la fois, à différents stades d'avancement.  
 
Dans ce cas-ci, une majeure différence est que le contrôlleur n'est plus une unité qui supervise l'ensemble des opérations d'au dessus. Elle est située au début du pipeline, et transforme les instructions ASM en une ou plusieurs (parfois bcp) µ-ops (appelées macro-ops chez AMD). Ensuite, ces µ-ops sont envoyées au travers de sheduler/dispatcher aux unités d'exécutions, qui vont elles-mêmes s'occuper de faire les opérations correspondants à ces µ-ops.
 
Pour la suite, tu peux lire ces articles, qui détaillent plus ce qui se passe dans un CPU récent. Mais je trouve que comprendre le fonctionnement d'une architecture plus simple permet de plus facilement se représenter le flux de données dans un CPU actuel.
 
http://www.hardware.fr/articles/249/page1.html
http://www.hardware.fr/articles/398/page1.html
 
 

Bon, pas du tout.
 
Il faut bien se rendre compte que quand on a plusieurs CPUs, le système d'exploitation alloue des process différents à chaque CPU.
Les CPUs travaillent donc dans un espace d'adressage différent, c'est à dire qu'ils n'accèdent jamais à la même zone de mémoire vive, et donc n'exécute jamais les même opérations.
 
PS: en fait, ce n'est pas tout à fait vrai, si un programme est composée de plusieurs taches différentes, séparées (cela est fait par le programmeur, l'OS ne sait pas faire cette séparation lui même), les CPU peuvent exécuter chacun une tâche du même programme. Ils pourront donc accéder aux même données dans le RAM, mais ce n'est pas pour cela qu'ils exécuteront le même code.
 
 

non, pas du tout:
le multi-core, c'est comme le multi-processeur, tu prends deux CPU complets (avec unités d'exécution, unités de controlle...) et tu les mets ensemble sur le même morceau de silicum. La seule chose qui est commune aux deux core est ce qui est nécessaire pour communiquer avec le monde extérieur au travers d'un bus quelconque.
 
Le controlleur du G5 est en effet un peu différent de celui du POWER4+ essentiellement pour pouvoir supporter (et donc décoder)  les instructions Altivec.
 
PS: les PPC n'ont pas 32 unités d'exécution !!! Aucun CPU au monde n'a autant d'unités, sauf peut-être les processeur vectoriel très spécifique qu'on trouve dans les Cray ou dans l'Earth Simulator de NEC. Tu dois confondre avec le nombre de registre non ? Il y en a 32 sur ces CPU. (32 registres généraux, il y en a en plus pour l'Altivec)
 
Bon voilà, c'était long, j'espère que c'est pas trop brouillon et que quelqu'un retirera quelque chose du temps que j'ai passé à ça

un cpu vectoriel ne fait que des traitements sur les virgules c'est çà ?  
le principe est il le même dans les unités de type Altivec ou SSE2 ?

Oui effecitivement les 32 c'est pour les registres généraux.
 
Mais je tiens tout de même à dire qu'un core n'est pas un microprocesseurs complet et d'ailleurs on le voit bien sur le schèma général du Power4.
 
Mon frère a été catégorique sur le Fait qu'une CPU n'est pas un microprocesseur entier.
 
Si le multicore n'était qu'une duplication du proc sur la même plaque Si cela ne se nommerait pas multicore.  
 
 
http://www-1.ibm.com/servers/eserv [...] ogical.jpg

sur ce lien on voit le schèma du POWER4 en Haut :"Processor core 1 et Processor core 2" tout le reste c'est pas les cores et on a les caches communes ou non, et un Fabric controler je ne sais pas à quoi ça correspond mais il est unique ,le GX controller est l'une des partie dévollue à la mise en parallélle (on est bien d'accord que le G5 ne possède pas cette unité GX)
 
Voilà,bon sur ton explicatif je ne comprends pas bien pourquoi un multicore aurait besoin d'une optimisation logiciel (pour l'OS peut être j'en sais rien)
Mais je vois que tu connaîs quand même.
 
Je vais formuler une hypothèse toute "bête" et si selon l'architecture multicore enployée y'avait besoin ou non d'une optimisation logiciel pour exploiter les deux cores?
C a d en gros et si on avait tout les deux raison?
Parceque je crois que les différentes puces multicore ne sont pas faites pareille(cache communes ou non ....)

oui, c'est exactement ça: faire la même opération sur plusieurs données en parallèle. Un processeur vectoriel fait ça, mais à une plu grosse échelle.

Bon ok, on peut sans doute séparer le "core" du reste du microprocesseur. Mais je continue de penser que µ-processeur et CPU sont des synonymes. Mais bon, comme je l'ai déjà dit, c'est juste une question de terminologie.
 
Alors, on peut en effet séparer, le core, qui est tout ce dont j'ai parlé dans mon précédent post (unités d'exécution mais aussi controlleur qui décode les instructions), d'autres unités: il s'agit essentiellement de la mémoire cache, et des composants qui servent à se connecter au bus qui va vers la carte-mère.
 
Le Fabric Controller est un gros switch qui permet de transférer les infos entre les CPU et les ports d'entrée-sortie. Le controlleur GX sert à faire du SMP et aux connexions vers les I/O. C'est donc normal que le G5 n'ai pas ces unités.
 

Car le contrôleur qui effectue le décodage des instructions et le contrôle des unités d'exécution se trouve dans le "core". Il y en a donc deux sur le Power4+. Un chip de ce type est donc vu comme deux processeurs séparés par l'OS. L'OS ne peut pas faire la différence entre un système SMP et multicore, il voit juste plusieurs CPU.
 

Ca dépend du point de vue: un software aura toujours besoin d'être écrit spécifiquement pour tirer partis d'un multicore. Mais c'est le même type d'optimisation qui est nécessaire pour du SMP ou pour de l'Hyperthreading. Ce genre d'optimisation apparait de plus en plus dans les logiciels pouvant en tirer un bénéfice. (pas dans Word quoi... )
 
Par contre, ce qui est possible de faire pour augmenter les perfs sans devoir optimiser, c'est d'ajouter des unités d'exécution dans le core. Par exemple, si tu regarde le schéma-bloc du K8 qui est plus haut, tu verras qu'il y a 3 unités ALU et trois unités FPU derrière le décodeur. Le problème, c'est que ça complique le controlleur qui doit gérer toutes les dépendances...

bououuu