A terme, ces processeurs auront des performances qui ne seront plus en relation directe avec leurs fréquences.
Cette situation risque de perdre le consommateur moyen, habitué depuis longtemps à n'accorder essentiellement que de l'importance au MHz ou au GHz.
# Re: AMD et INTEL optent pour des technologies opposées.
Posté par moulator . Évalué à 10.
Franchement, comparez-vous deux voitures en vous basant uniquement sur la vitesse de pointe ou le nombre de chevaux Din du moteur ?
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par analogue o/ (site web personnel) . Évalué à 3.
Voiture <-> Station
Moteur <-> Proc
Un rating incite la concurence a aller tjrs plus vite et c'est tant mieux, mais pas le Mhz =(
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par moulator . Évalué à 4.
[^] # La réponse est dans la question :
Posté par Jak . Évalué à 10.
-1 et je sors ...
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Éric (site web personnel) . Évalué à 10.
Donnes lui une autre référence et il l'utilisera. Le probleme c'est que cette autre référence elle n'existe pas trop : un proc n'est pas meilleur dans l'absolu, il est meilleur dans tel type de calcul et pas dans tel autre, il a tel jeu d'instruction en plus, il a .... le seul moyen de tester correctement tout ca c'est une série de bench, et encore : c'est loin d'etre parfait, donne des résultat difficile à interpréter pour un néophyte et dépend beaucoup du matériel à coté (difficile de ne comparer que le proc quand à la base ils sont montés sur des carte mere & chipset différents).
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par HappyPeng . Évalué à 3.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par matiasf . Évalué à 3.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par kesako . Évalué à 5.
faut comparer le couple !
la puissance n'etant que le couple multiplié par la vitesse de rotation.
tiens on revient au meme probleme que pour les Mhz : comment expliquer le couple a un profane ? la puissance c'est pus parlant , mais faut parler de puissance a un regime donné. Et qu'est ce que c'est la puissance a un regime donné ? ben, le couple !
:-)
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par boubou (site web personnel) . Évalué à 2.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par matiasf . Évalué à 1.
Tu vois mal le problème. Les voitures sont suffisament puissante à notre époque. Ce n'est pas parce que c'est un moyen de transport que le puissance est sans intérêt. Début du siècle précédent la puissance des véhicules étaient insuffisantes (quoique les routes, la culture ne permettait pas d'aller vite...). Les fusées ne sont que des moyens de transport et la puissance est très importante. Si un jour tu as la change d'utiliser un camping-car tu te plaindra souvent de leur faible puissance dans les montées.
> Pour un PC, la puissance est beaucoup plus utile que pour une voiture.
Toujours le même problème. Pour un usage bureautique tous les cpu sont assez puissants.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par okhin . Évalué à 2.
Voilà...
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Gniarf . Évalué à 2.
un bon vieux Doom marche très bien sur ces engins-là.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par wismerhill . Évalué à 2.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Gniarf . Évalué à 0.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Tutur . Évalué à 1.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Anonyme . Évalué à 1.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Moby-Dik . Évalué à 5.
Ah, toi aussi, tu profites de Noël pour rencontrer des vrais gens !
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Serge Rossi (site web personnel) . Évalué à 1.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par matiasf . Évalué à 2.
Si tu as le couple en fonction de la vitesse de rotation, tu as la puissance en fonction de la vitesse de rotation.
> la puissance n'etant que le couple multiplié par la vitesse de rotation.
Si tu n'a que le couple tu ne conclus rien. Si tu n'as que la puissance, tu as quelques éléments.
Il y a une forte corélation entre la rapport puissance/poid et les accélérations d'un voitrure (1000 m départ arrêté par exemple).
De même, pour un carosserie donnée, il y a une forte corélation entre la puissance et la vitesse maxi.
Exemple :
Moteur diesel : 300 Nm ; 100 KW => Vmax = 200 km/h
Moteur essence : 200 Nm ; 100 KW => Vmax = 200 km/h
Imaginons un moteurs de 100 KW à 8000 tr/min et 150 Nm à 4000 tr/min. Prenons le même moteur mais qui tourne deux fois moins vite et qui a un couple deux foi plus élevé (100 KW à 4000 tr/min ; 300 Nm à 2000 tr/min).
Les moteurs une fois installé dans un véhicule donnerons EXACTEMENT les même performances. Le seul point particulier est que le moteur qui tourne deux fois plus vite va envoir une boîte de vitesse deux fois plus courte !
Les moteurs diesel à puissance équivalente d'un moteur essence offre souvent de meilleur reprise. Je semble me contredire. En fait, les moteurs diesel on souvent un courbe de puissance mieux répartie que le moteur essence. A 50 % du régime de puissance, les moteurs essence ont 50 % de leur puissance maxi. Pour les moteurs diesel, à 50 % de leur régime de puissance, il ont souvent 60 à 65 % de leur puissance maxi.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Olivier Jeannet . Évalué à 1.
A la différence qu'un turbo permet à un diesel d'augmenter sensiblement son rendement (plus de puissance pour la même consommation, ou bien, ce qui revient au même, puissance égale et consommation moindre), au contraire d'un moteur à essence pour lequel la consommation augmente pas mal (ce qui explique pourquoi les turbo essences sont devenus rares).
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par matiasf . Évalué à 3.
Les moteurs diesel sont des moteurs a mélange pauvre et ne nécessite pas de boîtier papillon qui "étrange" l'arrivée d'air et engendre un phénomène d'aspiration à l'échappement qui n'aide pas.
Si les moteurs diesels avaient un boîtier papillon, il serait toujours totalement ouvert.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par kesako . Évalué à 0.
:-)
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par matiasf . Évalué à 1.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Yves Dessertine . Évalué à 3.
> faut comparer le couple !
> la puissance n'etant que le couple multiplié par la vitesse de
> rotation.
Vrai ! Calculez vous-même :
P(W) = C(N.m) * Vr(rad/s)
(y'a plus l'option «-1» ???)
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Croweye . Évalué à -2.
la puissance d'un moteur n'est psa directement en lien avec la cylindré
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Rin Jin (site web personnel) . Évalué à 10.
La plupart des consommateurs achétent un micro en fonction de la marque, du prix, simplement parce que ce sont aujourd'hui les deux critéres les plus sûrs (marque: on rassure le client, prix, on rassure le porte-monnaie)
Aprés il reste les petits crétins à la hfr, ceux là vont assimiler "parfaitement" ce nouveau truc et nous le ressortir à toutes les sauces, mais comme c'est souvent à ce genre de type qu'on demande conseil, le consommateur moyen se dit qu'il n'a pas à réfléchir et que l'on va comparer pour lui.
Ceux qui comparent VRAIMENT comparent tout et n'achéte pas à tort et à travers (par exemple, pas de carte vidéo à plusieurs milliers d'euro pour faire du traitement de texte) savent qu'il ne faut se fier uniquement au processeur, ni à sa vitesse.
A part ça, un peu plus de rigueur dans la rédaction de cet article aurait été parfait.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par philip . Évalué à 3.
et alors c'est pas vrai ?
->[]
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par pfrenard . Évalué à 1.
avec Flash et toutes ces conneries .. ca fait pas de mal d'avoir un bon CPU
effectivement ca accelere pas internet mais ca fait mieux tourner quand on est dans le brouteur !
Bref l'utilisateur moyen il voit que ca accelere
Sinon faudrait qu'un organisme independant nous fasse un rating qui va bien
La presse informatique PC grand public a deja ce genre de chose avec des classement lie a l'utilisattion ( bureautique, jeux, musique, video .... ) mais tout ca pour un pc complet.
Si ou veut le faire element par element ca va nous en faire des tableaux a multientrees
CPU / Carte Mere / Memoire / disque dur / Carte Video
Gloops
a+
# Re: AMD et INTEL optent pour des technologies opposées.
Posté par analogue o/ (site web personnel) . Évalué à 2.
A quand un rating basé sur SPECint ou autre ? Ca ferait du bien aux archis alternatives en plus =)
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Richard Van Den Boom . Évalué à 10.
La vérité, c'est qu'une échelle de performance, c'est assez compliqué à trouver, surtout quand il s'agit de comparer des architectures très différentes. Il n'y a pas de formule magique, il faut se faire une idée en comparant les architectures sur les applications que l'on compte utiliser.
Personnellement, je vais sur le site www.aceshardware.com, ils y font peu de revues, mais bien documentées et les gars savent ce qu'ils testent, contrairement à la grande majorité des sites de matériel. Le forum est aussi assez intéressant car il y a plusieurs ingénieurs et informaticiens visiblement compétents qui contribuent. Evidemment, comme dans tout forum, il y a toujours des excités un peu fanatiques qui cherchent à défendre telle ou telle marque, mais globalement, on peut avoir des analyses et des informations techniques d'assez haut niveau.
Cordialement,
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Schwarzy . Évalué à 10.
Donner du code optimisé P6 (686) à un P4 et les performances plongent. Le P4 a modifié (et surtout augmenté) les temps de latences de diverses instructions. Pour exploiter au mieux le P4, il faut recompiler le programme en utilisant un compilo capable de reconnaître les nouveaux "ordonancements".
La longueur du pipeline du P4 (porté à 20 niveaux) fait aussi beaucoup souffrir du code qui se prend souvent des pénalité d'enbranchement.
Bref, le P4 est quelque part un changement d'architecture dans la veine des x86. Et comme tout changement d'architecture, cela pose beaucoup de problèmes. A l'opposé, AMD en assurant un comportement identiques avec le vieux code est rassurant.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
"La première sécurité est la liberté"
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Arachne . Évalué à 2.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Marc (site web personnel) . Évalué à 9.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par okhin . Évalué à 3.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par reno . Évalué à 4.
Bin pourquoi????
Il y a deux manieres de faire des CPU: les speed daemon (1) et les brainiac (2).
1: on construit le CPU de telle maniere qu'il puisse aller tres vite, meme s'il ne peut pas faire grand chose a chaque cycle
2: le CPU a une fréquence d'horloge plus basse mais arrive a faire plus d'instruction simultanément.
Il n'y a PAS une facon meilleure que l'autre, pourquoi aurait-tu préférer un P4 moins rapide? Qu'est ce que tu en as a faire de la vitesse d'horloge???
Ce qui compte c'est les SpecInt, SpecFP et le rapport SpecMachin/prix, la vitesse d'horloge n'a aucune importance!
PS:
j'exagere quand meme: les speed daemon sont en général moins bon sur du code non-optimisé pour ce type de CPU, mais le probleme se pose aussi sur des brainiac: certaines unités seront sous-utilisées si le compilateur a optimisé pour une autre architecture.
# Re: AMD et INTEL optent pour des technologies opposées.
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
# Re: AMD et INTEL optent pour des technologies opposées.
Posté par Xmanu . Évalué à 2.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par bib . Évalué à 1.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Gaétan RYCKEBOER . Évalué à 7.
Un instruction peut prendre 30, 40, 50 cycles si elle est complexe.
De plus, les opérations de base prenne presque toujours plus d'un cycle d'horloge.
Enfin, l'article en question ne parle pas de choix technologiques différents pour AMD et Intel, il parle du numéro marqué sur le boiteir. L'accroche de la new linuxfr est donc fausse.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
Tu parles de quoi là, CISC ou RISC ?
C'est généralement vrai en RISC. C'est plus rarement vrai en CISC.
Un instruction peut prendre 30, 40, 50 cycles si elle est complexe.
Div flottant ou sin qui n'existe pas en RISC en général.
De plus, les opérations de base prenne presque toujours plus d'un cycle d'horloge.
Heureusement que non !
"La première sécurité est la liberté"
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Moby-Dik . Évalué à 1.
Note que dans F-CPU, une addition de plus de 8 bits est prévue pour prendre plusieurs cycles ;)
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Mais tu as mal lu, il est question de latence de pipeline !!!! L'addition se fera toujours en un cycle.
"La première sécurité est la liberté"
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par gege . Évalué à 1.
# N'importe quoi
Posté par Moby-Dik . Évalué à 10.
Poubelle.
[^] # Re: N'importe quoi
Posté par Nicolas Boulay (site web personnel) . Évalué à 8.
Surtout que le P4 inclue le SSE2 que n'a pas l'Athlon (SIMD avec des doubles).
La comparaison Pentium et 486 est pas mal non plus, l'explication est donné avec les caches alors que c'est l'utilisation de 2 pipelines qui accélèrent les traitements (superscalair 2-way)!
"La première sécurité est la liberté"
[^] # Re: N'importe quoi
Posté par Tom D . Évalué à 7.
Pourtant, les chips CISCs ne sont plus nécessairement les plus rapides !
Il vient de ou ce "pourtant"? A-t-on sous-entendu le contraire precedement? Je pensais que c'etait les processeurs RISC qui avaient la reputation d'etre rapide...
Un CPU CISC aura besoin d'une seule instruction (donc d'un cycle) pour effectuer une divison tandis que le RISC aura besoin de 50
Euh, c'est pas ce qu'on dit la :
http://www.iro.umontreal.ca/~dift1225/performances.html(...)
RISC : Reduced Instruction Set Computer
[...]
- On veut un cycle par instruction.
Comparons un 486DX4/100 Mhz (CISC) qui obtient 6 MFLOPS et un R10000 200 Mhz (RISC) obtenant, lui 400 MFLOPS ! Ces chiffres illustrent bien la non-linéarité entre fréquences et performances! Le MFLOPS est encore trés couramment utilisé malgré ces inconvenients majeurs !
Moi je ne trouve pas qu'il s'agisse d'un inconvenient majeur d'observer la non linearite entre MHz et MFLOPS, c'est le but, non?
Bon, je n'ai pas de clavier AZERTY, mais "tres", l'accent est dans l'autre sens.
Tom
[^] # Re: N'importe quoi
Posté par bib . Évalué à 2.
* Computer ? --> Chip ?
* Juste, mais il a aussi le désavantage de dépendre énormément du type de calcul éffectué.
[^] # Re: N'importe quoi
Posté par Schwarzy . Évalué à 8.
Beaucoup, beaucoup d'aproximation dans cette article.
Premièrement, les raccourcis RISC/CISC n'ont plus de sens depuis plusieurs années dans le monde du server/desktop. En simplifiant, les processeurs x86 ont un coeur RISC et un front-end pour les instructions CISC x86. Mais la réalité des "RISC" modernes comme le PowerPC est qu'ils ont du intégrer des améliorations "CISC" comme la mémoire cache ou la prédiction de branches pour gagner en performances. Les instructions SIMD des CISC ont aussi fait leur chemins dans le monde RISC desktop (la réalité est d'ailleurs que le SIMD vient du monde des DSP). Aujourd'hui, il n'y a plus un grand écart entre le nombre d'instruction d'un CISC x86 et d'un RISC PowerPC.
La distinction RISC/CISC se trouve encore dans le petit "embarqué". Les RISC se prêtent bien au "pipelining" des instructions contrairement au CISC. On gagne donc en nombre d'instructions par cycle tout en gardant la même fréquence (5 - 30 Mhz) et presque la même consommation électrique (et c'est très IMPORTANT dans l'enfoui). Le nombre élevé de registres dans le RISC est un plus dans la course au performance puisque on limite les accès mémoires dans des boucles de calculs.
[^] # Re: N'importe quoi
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
ça c'est du buz word. C'est l'ISA qui est CISC pas le processeur ! Car dans ce cas des processeurs RISC ont des coeurs CISC (cf DLX) !
des améliorations "CISC" comme la mémoire cache ou la prédiction de branches pour gagner en performances.
gni ? le rapport avec la choucroute ? RISC/CISC qualifie l'ISA pas la microarchitecture !
(la réalité est d'ailleurs que le SIMD vient du monde des DSP).
Perdu ! Cela vient des supercalculateurs "vectoriels" comme les Cray.
La distinction RISC/CISC se trouve encore dans le petit "embarqué". Les RISC se prêtent bien au "pipelining" des instructions contrairement au CISC.
C'est vrai.
On gagne donc en nombre d'instructions par cycle tout en gardant la même fréquence (5 - 30 Mhz) et presque la même consommation électrique (et c'est très IMPORTANT dans l'enfoui).
La phrase est ambigüe. Disons qu'à complexité égal, un processeurs RISC monte à plus haute fréquence (souvenez vous des premiers alpha).
Pour la consomation élèctrique, il y a d'autres facteurs qui rentre en jeu.
Le nombre élevé de registres dans le RISC est un plus dans la course au performance puisque on limite les accès mémoires dans des boucles de calculs.
C'est la conséquence du gain de place que l'on a en virant l'inutile. Mais ce n'est pas réservé au RISC. Il suffit de voir les nouveaux DSP texas qui ont des instructions, 16 32 48 bits... pour gagner en taille de code (un code ARM thumb est bien plus gros que du code "normal" x86).
"La première sécurité est la liberté"
[^] # Re: N'importe quoi
Posté par Schwarzy . Évalué à 2.
> RISC/CISC qualifie l'ISA pas la microarchitecture !
Et le but originel de faire un ISA simplifié n'était-il pas de faire une microarchitecture plus légère ? De plus tous les papier que j'ai lu associait fortement l'ISA avec la microarchitecture ce qui me semblent logique.
Au passage, j'ai mis avant ma phrase En simplifiant. Donc au lieu de sortir une vérité de ma phrase qui n'y est pas, merci de correctement me citer. Ma logique était dans l'architecture des processeurs modernes qui emprunte aux CPU RISC pour les coeurs dans le but de monter en fréquence et puissance.
>Perdu ! Cela vient des supercalculateurs "vectoriels" comme les Cray.
hummm.. on m'aurai menti ? mais c'est vrai que le Cray est ancient et est à l'origine de vecoriel. Mea culpa.
> La phrase est ambigüe.
A quel niveau ? Je ne te suis pas.
>(un code ARM thumb est bien plus gros que du code "normal" x86)
Ouh la, je ne m'aventure pas dans ce genre de "vérité". Déja, faudrait définir un code "normal" x86. J'ai vu de cas sur des routines où le x86 est trop gros et des cas où l'ARM thumb est plus gros. Classer la taille de code, c'est partir des besoins applicatif pour faire des mesures. C'est comme ça que cela se passe où je travaille et les experts ne font pas confiance au marketing. Le code fait maison est envoyé au fournisseur qui doit renvoyer la taille de code obtenue et les performances en calcul.
[^] # Re: N'importe quoi
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
si. L'utilisation de décodage puis de micro instruction, aussi. Mais il ne s'agit pas de mettre un risc derrière le décodeur (cela plutot ressembler à un vliw d'ailleurs).
>(un code ARM thumb est bien plus gros que du code "normal" x86)
J'ai vu ça dans un comparatif de compilation de différent fichier .c, puis gzipper comparant ARM (compilo arm et gcc), x86, Sparc (Leon).
Je dis "normal" pour le x86, car il utilisait -02 au lieu de -0s comme switch pour gcc. Et la différence était assez importante.
"La première sécurité est la liberté"
[^] # Re: N'importe quoi
Posté par Paerro Trime . Évalué à 1.
Sur le desktop, on l'oublie souvent mais Sun a tiré le premier avec l'ultrasparc I, nettement avant intel et son MMX (de merde).
[^] # Re: N'importe quoi
Posté par reno . Évalué à 1.
En partie seulement: il y avait aussi l'idée de faire une ISA adaptée au compilo: les bizarrerie des 80x86 ne facilite pas la vie pour optimiser, meme a la main, alors pour un compilateur..
Au fait merci Nico: ça fait du bien de lire que le RISC et le CISC sont liés a l'ISA pas a l'implémentation!
Pourtant il y a bien marqué IS (Instruction Set): Jeu d'Instruction dans les noms!
Pour info il y a des RISC qui ont été implémentés avec des micro-opérations comme les CISC étaient fait avant..
Sinon pour ce qui est du SIMD, je chipoterais un peu: le SIMD vient au départ des implémentations hardware dédié avant les Cray, mais c'est vrai que le Cray a été le premier CPU a l'implémenté.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: N'importe quoi
Posté par Richard Van Den Boom . Évalué à 2.
Comme quoi, des innovations, il y en a eu dans les deux sens et les deux architectures ont bénéficié des avancées de l'autre.
Il faut aussi préciser que, au delà des jeux d'instructions proprement dits, les processeurs actuels du monde x86 sont des RISCs qui se cachent : en effet, tous incorporent en réalité une étape de décodage des instructions x86 en micro-instructions de type RISC, plus faciles à éxécuter dans le désordre.
Cet discussion CISC contre RISC n'a plus aucun sens de nos jours. Elle n'incorpore même pas les jeux d'instruction VLIW qui commencent à apparaitre avec les processeurs de Transmeta ou l'Itanium d'Intel.
Cordialement,
[^] # Re: N'importe quoi
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Yep parce que les processeurs RISC n'ayant pas encore les poids des années et de la compatibilité n'en avait pas (encore) besoin.
Lorsque l'alpha à eu un core OO, il a pris 45 millions de transistors en +...
Il faut aussi préciser que, au delà des jeux d'instructions proprement dits, les processeurs actuels du monde x86 sont des RISCs qui se cachent : en effet, tous incorporent en réalité une étape de décodage des instructions x86 en micro-instructions de type RISC, plus faciles à éxécuter dans le désordre.
microinstruction, microcode, s'est pareil ! je persiste à insister : RISC/CISC qualifie le jeu d'instruction pas leur implémentation !
Cet discussion CISC contre RISC n'a plus aucun sens de nos jours. Elle n'incorpore même pas les jeux d'instruction VLIW qui commencent à apparaitre avec les processeurs de Transmeta ou l'Itanium d'Intel.
Yep ! Les dsp TI aussi (vliw 8 voix)
"La première sécurité est la liberté"
[^] # Re: N'importe quoi
Posté par Richard Van Den Boom . Évalué à 1.
Je ne sais pas si on pas si c'est trop ça. Ce n'est pas tant une raison de compatibilité que de vouloir augmenter l'IPC du processeur à même fréquence. Augmenter la fréquence pose parfois des problèmes, car elle nécessite des outils de gravure de plus en plus affinés, qui ne sont pas forcément disponibles. C'est aussi ce qu'à rencontré DEC avec le 21164. Donc, pour augmenter malgré tous les performances, on augmente l'IPC. Et le OoO permet en partie d'éviter les états d'attente des processeurs superscalaires en cas d'instructions indépendantes.
Ainsi le PPro a augmenté sensiblement les performances du Pentium à même fréquence, en restant (si je me souviens bien) en gravure 0.35µ, tandis que l'Alpha 21264 a doublé celle du 21164 à même fréquence et même finesse de gravure (0.25µ là encore si je me souviens bien).
> RISC/CISC qualifie le jeu d'instruction pas leur implémentation
Autant que je sache, c'est exact.
Cordialement,
[^] # Re: N'importe quoi
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Augmenter la fréquence pose parfois des problèmes, car elle nécessite des outils de gravure de plus en plus affinés, qui ne sont pas forcément disponibles.
Euh, pour une techno donné le temps de parcoure d'une porte est fixe. Tu peux mettre plein de portes en parrallèle (ipc monte), moins de porte entre 2 registres (pipeline, frequence monte), ou refaire le routage (moins de temps perdu dans les fils, la fréquence monte).
Ou changer de techno. Il n'y a pas de problème d'outils, c'est bettement physique (la NAND elle a besoin de 15 ps, il ira pas plus vite en changeant d'outils).
"La première sécurité est la liberté"
[^] # Re: N'importe quoi
Posté par Richard Van Den Boom . Évalué à -1.
En quoi est-ce contradictoire avec ce que j'ai dit? L'introduction des architectures OoO s'est généralement faites à même fréquence et même technologie de gravure que l'architecture In-Order. Cela correspond à ton premier cas.
A l'époque, elle représentait le meilleur rapport changements-gains, c'est pourquoi elles ont été appliquées. Les autres techniques sont également appliquables mais ont leur limitations. En générale, la manière la plus simple et la moins couteuse est d'affiner la gravure, ce qui permet souvent au passage d'autres améliorations, surtout au niveau du cache et la baisse de consommation thermique. C'est généralement ce qui est arrivé avec le PII puis PIII, le P4 et l'Athlon original. Pour l'Athlon XP, le changement de finesse de gravure n'a pas vraiment suffit à faire monter la fréquence de façon significative, d'où la nécessité de refaire l'architecture, avec Hammer.
La finesse des outils de gravure a un impact considérable sur la fréquence des processeurs, la longueur des traces, la taille du cache, etc. Le fait que l'on ait diviser la finesse de gravure par 3 en 5 ans montre l'impact énorme qu'elle a.
Cordialement,
[^] # Re: N'importe quoi
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
C'est cette expression qui m'a enduit d'erreur. Je croyais que tu parlais d'outils informatique.
On parle de finesse de gravure, de largeur de grille mais pas de finesse des outils de gravures (il n'utilisent pas des burrins de 0.09µm...). :)
"La première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: N'importe quoi
Posté par Gaël Le Mignot . Évalué à 5.
Stop. Le Pentium Pro n'est pas un processeur CISC. Le PPro et les processeurs suivants chez Intel, ainsi que le K6 et suivants chez AMD sont des processeurs à coeur RISC mais interface CISC. Une partie de processeur "décode" chaque instruction CISC x86 (et autres extensions) en une série d'instruction RISC. Le coeur d'exécution, lui, est RISC. Et la nécessité d'un core OO est apparu uniquement, à cette époque, à cause de la piètre qualité de la traduction x86 => instructions internes, tout ça au prix d'un nombre énorme de transitor, uniquement au nom de la sacro-sainte compatibilité binaire, qui est un autre effet pervers des logiciels non-libres.
[^] # Re: N'importe quoi
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
RISC cela veut dire reduice INSTRUCTION SET computer.
INSTRUCTION SET !!! pas micro-architecture ! (Même si cela aide à la faire évoluer !)
Donc tous les x86 seront et sont TOUJOURS des Cisc. Point barre.
Qu'il utilise en interne ce qu'il veulent, cela sera toujours des CISC. Sinon, on peut dire que des implémentation de MIPS ne sont pas RISC mais CISC car microcodé (DLX et autre) ? Cela serait complétement idiot !
De toutes façon, quelque soit la forme du coeur d'execution, le décodeur devra toujours exister !
C'est d'autant plus idiot que les coeurs de proc x86 doivent beaucoup plus ressembler à des vliw qu'autre choses.
"La première sécurité est la liberté"
[^] # Re: N'importe quoi
Posté par Tom D . Évalué à 2.
Il semblerait que c'est bien "computer" :
http://www.instantweb.com/foldoc/foldoc.cgi?query=risc&action=S(...)
Google a recherché "Reduced Instruction Set Computer" sur le Web. 1 - 10 résultats, sur un total d'environ 15,400.
Google a recherché "Reduced Instruction Set Chip" sur le Web. 1 - 10 résultats, sur un total d'environ 457
une seule instruction (donc d'un cycle)
Hum, http://216.239.53.100/search?q=cache:RIgUI2kYIkEC:www.cs.sjsu.edu/f(...)
Tom
[^] # Re: N'importe quoi
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
Les CISC sont à prioris plus lent car il consacre + de silicium à des trucs pas vraiment utile contrairement au RISC (nue règle de 80-20, vaux mieux optimiser à fond 80% des instructions les plus utiliser que ce faire chier avec les 20% restant complexe et qui ralentissent tout)
M'enfin, les x86 déchirent tous en ce moment. Les Power 4 trichent au specint (durant les tâches mono-proc, les processeurs idle faisait des prefetch pour le caches L3 !), les SPARC64 ne sont toujours pas disponibles.
Un CPU CISC aura besoin d'une seule instruction (donc d'un cycle) pour effectuer une divison tandis que le RISC aura besoin de 50
L'exemple est mal choisi mais c'est l'idée.
En CISC tu peux faire:
ADD [R1 + R2 + 8] [R2 + R3 + 4] (opération mémoire mémoire)
En RISC, tu auras :
ADD R1 R2 R4
ADD R4 #8 R4
ADD R2 R3 R5
ADD R5 #4 R6
LOAD [R5] R7
LOAD [R6] R8
ADD R7 R8 R9
STORE R9 [R6]
Mais personne n'utilise ses adressages complexes.
RISC:
- On veut un cycle par instruction.
Mouais, sauf quand c'est pas le cas : genre les instructions fpu sparc qui prenne 3 cycles par instructions.
Il reste juste 2 choses : mots d'instructions de taille fixe (pour simplifer le decode et le fetch), nombre de cycles par instructions de durés fixes (évite des microcodes à la mord moi le noeud)
nicO, f-cpuer
"La première sécurité est la liberté"
[^] # Re: N'importe quoi
Posté par Duncan Idaho . Évalué à 1.
C'est pas l'inverse plutot ? 20% du truc qu'il faut optimiser parce que c'est le plus utilisé, les 80% restant étant peu utilisé n'ont pas d'impact sur la vitesse de l'algorithme.
[^] # Re: N'importe quoi
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Je considérais que 20% des instructions prennait 80% des ressources hardware comme dans l'exemple
ADD [r1 +r2 +8] [r2+r3 +4]
M'enfin, c'est l'idée.
"La première sécurité est la liberté"
[^] # erreur or not ?
Posté par snurpsss . Évalué à 1.
ADD [R1 + R2 + 8] [R2 + R3 + 4] (opération mémoire mémoire)
En RISC, tu auras :
ADD R1 R2 R4
ADD R4 #8 R4
ADD R2 R3 R5
ADD R5 #4 R6
LOAD [R5] R7
LOAD [R6] R8
ADD R7 R8 R9
STORE R9 [R6]
je crois avoir deceler une tite erreur (mais je peux me tromper , mes rudiments en assembleur sont loins )
ADD R1 R2 R4 ok
ADD R4 #8 R4 ? R4 + #8 dans R4 ? ca serait pas R4 +#8 dans R5?
ADD R2 R3 R5
ADD R5 #4 R6 ? ici on a bien R5 + #4 dans un nouvel espace memoire ?
LOAD [R5] R7
LOAD [R6] R8
ADD R7 R8 R9
STORE R9 [R6]
donc soit la ligne 2 devient ADD R4 #8 R5 , soit la ligne 4 devients R5 + #4 R5 , avec les ajustements sur les lignes qui suivent evidement
qqu un peut confirmer ?
[^] # Re: N'importe quoi
Posté par Tutur . Évalué à 1.
en CISC, tu utilises les registre R1 à R4
en RISC, tu utilise les registre R1 à R9
Pourquoi, en risc tu n'utilses pas le même registe en cource et destination?
Sinon, ce petit exemple montre bien les differences entre du CISC et du RISC. Le CISC implique des buffers interne, or les buffers bouffent beaucoup de place sur le silicium.
[^] # Re: N'importe quoi
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Le problème c'est surtout l'enchainement des événements qui est complèxe à gérer surtout lorsque l'on rajoute la gestion des exceptions (venant de la VM,...). Plus les problèmes liés au microcodes. Et ensuite, lorsqu'il faut accélérer et pipeliner tout ce petit monde...
Pourquoi, en risc tu n'utilses pas le même registe en cource et destination?
Par ce que dans un processeur risc, c'est le plus souvent le cas (et c'est très pratique pour diminuer les dépendances de flot read-after-write que n'aime pas du tout les pipelines).
"La première sécurité est la liberté"
# Et pourquoi pas calculer au MIPS ?
Posté par David Bober (site web personnel) . Évalué à 2.
# L'intérêt de la fréquence
Posté par wismerhill . Évalué à 3.
Toutes les mesures de puissance d'une machine dépendent de la façon dont est exécuté ce test, et suivant le test utilisé on peut avantager plutôt une architecture ou une autre.
[^] # Re: L'intérêt de la fréquence
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Pas forcément, car le bus mémoire ne change pas de vitesse (en général). Les P4 1,5 Ghz ou 3,06Ghz utilisent tous de base la RDRAM 800. Cela m'étonnerait que le 3,06 soit 2x plus rapide que le 1,5Ghz (sans tenir compte de l'hyperthreading évidement).
"La première sécurité est la liberté"
[^] # Re: L'intérêt de la fréquence
Posté par analogue o/ (site web personnel) . Évalué à 1.
Après, la vitesse d'execution de la babasse entiere depend de tous les autres composants, mais ca n'est pas le sujet.
[^] # Re: L'intérêt de la fréquence
Posté par wismerhill . Évalué à 4.
Je sais bien que celà est presque illusoire, cependant voici une expérience vécue: J'ai récament remplacé mon athlon 600 par un athlon XP 2200 (1800 MHz réels). j'exécute le client seti@home sur ma machine, avec l'athlon 600 une unité de calcul prenait ~14h de temps processeur pour être complétée, avec le XP2200 une unité de calcul prend ~4h. 14h/4h=3.5 et 2200/600=3.666 (1800/600=3). Ce n'est pas très étonnant, car le programme (~350ko dont beaucoup de code qui ne sert que lors du démarrage ou de l'envoitdes résultat et de la récupération de la suivante) et les données (~340ko) sont à peine plus grand que les différetns caches (128ko de L1 et 256ko de L2), d'où très peu de latence pour les accès mémoire, vu qu'à peu près tout peut tenir en cache.
[^] # Re: L'intérêt de la fréquence
Posté par Paerro Trime . Évalué à 1.
L'hyperthreading de toute façon ça change pas grand chose en moyenne.
[^] # Re: L'intérêt de la fréquence
Posté par wismerhill . Évalué à 1.
[^] # Re: L'intérêt de la fréquence
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Les techno SMT sont beaucoup plus finaudes que ça.
En fait, les process sont également utilisé pour combler les bulles dans chacun des 5 pipelines d'execution. C'est pour cela que le gain de vitesse max , se fait avec un process utilisant le nombre flottant et l'autre les nombres entiers.
"La première sécurité est la liberté"
[^] # Juste une question ...
Posté par Jak . Évalué à 1.
[^] # Re: Juste une question ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Juste une question ...
Posté par Jak . Évalué à 3.
D'autant que les quelques trucs sur le SMT que j'ai sont du Dr. Joël Emer, un gars qui a bossé sur l'EV8 (Alpha 21464) qui aurait dû être un SMT 4 voies, et qui bosse maintenant pour Intel.
[^] # Re: Juste une question ...
Posté par Paerro Trime . Évalué à 2.
# Une nouvelle mesure: MLCPS
Posté par Lorenzo B. . Évalué à 8.
Ça au moins c'est du concret, tu sais combien de litres de café préparer.
Bon ok, pour l'instant c'est inférieur à 1x10^-7 et donc pas très marketing, mais quand on aura nos pc quantiques, waou.
J'ai eu du + de 3h, puis 40', puis 12' et maintenant env. 4' pour compiler un noyau. Je change de matos pour gagner un facteur 3, avec un an de retard sur le « top ».
L'autre jour je lisais un article dans Pc Expert (quelle dérision) au sujet du nouvel Athlon. Le journaleux était franchement soulagé que AMD sorte une nouvelle mouture de son proc pour combler son retard considérable sur Intel. Tu te dis, super, ils ont doublé les perfs. Tu parles, le mec s'est fait un délire pour 10 malheureux % ! Ils marchent sur la tête.
[^] # Re: Une nouvelle mesure: MLCPS
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Sauf qu'il est dédié à la plateforme x86. Il faudrait un gros programme qui n'a pas de #define en fonction de sa plateforme pour en faire un vrai bench.
"La première sécurité est la liberté"
[^] # Re: Une nouvelle mesure: MLCPS
Posté par Gaétan RYCKEBOER . Évalué à 1.
Sinon, t'as même pas le temps de le faire, le café.
[^] # Re: Une nouvelle mesure: MLCPS
Posté par wismerhill . Évalué à 3.
De toute façon c'est pas un bon bench, ça dépend du compilateur utilisé, et même des optimisation utilisée pour la compilation du compilateur!
[^] # Re: Une nouvelle mesure: MLCPS
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Car linux ne se compile QUE avec gcc et gcc ne se compile qu'avec gcc (il me semble) et c'est le seul programme qui ne compile qu'avec -02 -g que j'ai vu.
D'ailleurs le bench peut être : compile de linux 2.4.18 avec tel .config avec gcc 3.2.0.
"La première sécurité est la liberté"
[^] # Re: Une nouvelle mesure: MLCPS
Posté par wismerhill . Évalué à 1.
Et ça oblige à garder un noyau 2.4.18 ET un gcc 3.2.0 dans un coin si tu veut pouvoir continuer à comparer, et il faut activer les même options de compilation et d'optimisation à chaque (au détriment des spécificités du pocesseur).
Conclusion: ben c'est difficile de comparer :-/
# Re: AMD et INTEL optent pour des technologies opposées.
Posté par Serge Rossi (site web personnel) . Évalué à 5.
http://www.linuxhardware.org/article.pl?sid=02/10/01/1241218&mo(...)
Si on teste P4 et XP sous Linux, la différence est encore plus à l'avantage de l'Athlon XP que sous Windows. Ce qui est normal puisque le P4 dépend plus d'optimisations du compilateur que le XP. Optimisations dont gcc ne dispose pas forcément.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par analogue o/ (site web personnel) . Évalué à 2.
Y a des cartes meres avec procs fabriquees en France:
http://thendipo.alias.domicile.fr/fr/feat_peg.htm(...)
Ou pour les feignants, acheter un CoinCoin =)
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Richard Van Den Boom . Évalué à 1.
Parceque, pour avoir les perfos d'un Duron 800Mhz, ca a intéret à être bon marché. Surtout quand tu vois le prix maintenant d'un Athlon XP 1.5Ghz. :-)
Cela dit, ca doit être bien silencieux, bien pour une set-top.
Cordialement,
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par _alex . Évalué à 2.
et http://www.aps.fr/(...)
Par contre ya un ventillo quelque part ou est-ce le silence le plus complet (dans ce cas ca m'interesse) ?
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par analogue o/ (site web personnel) . Évalué à 1.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Richard Van Den Boom . Évalué à 3.
A ce prix là, mieux vaut encore une carte mère Socket 370 et un processeur VIA C3 933MHz. Ca, je sais que c'est compatible avec tout et ca fonctionne sans problème sans ventilateur, avec juste un radiateur passif. Et ca me coutera 4 fois moins cher pour des performances similaires.
Dommage.
Cordialement,
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par analogue o/ (site web personnel) . Évalué à 1.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Tony Cheneau (site web personnel) . Évalué à 2.
Je crois que Macintosh ne met plus de ventilo sur ses procs depuis qu'il fait des G3 et G4.
Je sais qu'avec mon G3, en calcul intensif, je ne dépasse jamais les 50 degrés. Le fait qu'il n'y ai pas de ventilo est aussi assez interressant d'un point de vu embarqué car cela fait ca de moins du point de vu de la consommation.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par _alex . Évalué à 1.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Mathieu Pillard (site web personnel) . Évalué à 3.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par snurpsss . Évalué à 1.
ca m interresse , g un bi athlon Mp
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Mathieu Pillard (site web personnel) . Évalué à 1.
tu peux tester si ton systeme est affecte en compilant quelque chose avec par exemple:
gcc -Q -v $CFLAGS -mmx -3dnow blah.c -o blah
personellement je m'apercois que gcc rajoute un -mno-mmx et un -mno-3dnow
mes CFLAGS sont :
-march=athlon-tbird -O3 -pipe -fforce-addr -fomit-frame-pointer -falign-functions=4 -maccumulate-outgoing-args
voila voila...
vers la fin ce thread la http://forums.gentoo.org/viewtopic.php?t=5717(...) a quelques infos.
faudrait regarder les archives de la mailing list gcc mais jai la flemme :)
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Mathieu Pillard (site web personnel) . Évalué à 1.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Gniarf . Évalué à 5.
c'est surtout que le Pentium 4 a des optimisions complètement différentes du Pentium 3 et ses ancêtres.
entre autres blagues, certaines optimisations prévues pour les générations précédentes sont carrément catastrophiques sur un Pentium 4...
# Re: AMD et INTEL optent pour des technologies opposées.
Posté par fabrice Mercier . Évalué à 2.
Je doute mais je suis pas sûr.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
En général cela tourne autour du nombre de bits même en entier.
"La première sécurité est la liberté"
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Yohann (site web personnel) . Évalué à 1.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Gaël Le Mignot . Évalué à 2.
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par fabrice Mercier . Évalué à 3.
Les articles du genre "moi je sais tout les autres ce sont des gros nuls" ne devraient pas paraître sur un site tel que linuxfr.
# Re: AMD et INTEL optent pour des technologies opposées.
Posté par _alex . Évalué à 1.
Enfin pour l'instant, de ce que je vois ce que tout les CPU > 1.8Ghz me suffisent amplement (avec un duron 750mhz ut2003 rame un peu donc je pense qu'a 1.8Ghz ca suffit amplement), après je voudrais un truc silencieux.
NB: Faudrait aussi qu'on m'explique pourquoi mon pc émet un son aigu une fois éteint, depuis que j'ai installé un lecteur DVD....
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Concernant les applications oui, tu as raison. Demain, prend un athlon normal, tu lui double le nombre d'unité SSE et PAF tous les jeux 3D ont des perfs qui explose. Mais le reste (la bureautique) ramera toujours autant.
Ensuite, tu as l'influence des caches. Un petit calcul bourrin de 200ko se fout d'être dans un cache de 1Mo ou 128 Mo mais pas une grosse base de donné.
"La première sécurité est la liberté"
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.