Articles précédents : Articles
- [10] Rétrospective Mozilla de l'année 2002
- [18] Concours de programmation de jeu libre pour la fête de l'Internet
- [33] XBOX Linux : l'identité du généreux donateur révélée
- [19] 2003, année d'anniversaire... et de manifestation en France
- [5] Appel d'offre Zope au ministère de l'intérieur français
- [4] Catalogue des logiciels libres par la FSF et l'UNESCO
- [11] Pétition pour le libre au Brésil
- [19] Trop classe un bijou GNU(?)/Linux pour Noël !
- [29] Le gouvernement indien investit dans Linux
- [37] Eclipse avec GCJ: un environnement de développement libre
Liens connexes
Dépêche modérée par
Articles : AMD et INTEL optent pour des technologies opposées.
Posté par bib (page perso, ). Modéré le 03 janvier 2003.
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.
![[fr]](../../../images/fr.png)
![[en]](../../../images/en.png)
> Lire la dépêche (112 commentaires, moyenne: 3,2).
Re: AMD et INTEL optent pour des technologies opposées.
Le consommateur moyen n'aura qu'à réfléchir un peu plus.
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/ (page perso, ) le 03/01/2003 à 11:18. (lien). Évalué à 3.Une voiture, rarement, mais un moteur oui. Il faut comparer ce qui est comparable
Voiture <-> Station
Moteur <-> Proc
Un rating incite la concurence a aller tjrs plus vite et c'est tant mieux, mais pas le Mhz =(--
Votez contre le cinéma sur DLFP: http://linuxfr.org/tracker/296.html
Le lien pour voter est en haut à droite.-
[^]Re: AMD et INTEL optent pour des technologies opposées.
Posté par moulator () le 03/01/2003 à 12:42. (lien). Évalué à 4.Comment expliquer alors que le consommateur moyen se permette de comparer les MHz alors que les processeurs ne sont même pas de la même marque ?!?
-
[^]La réponse est dans la question :
-
[^]Re: AMD et INTEL optent pour des technologies opposées.
Posté par Éric (Jabber id, page perso, ) le 03/01/2003 à 15:20. (lien). Évalué à 16.tout simplement car on lui a dit que la puissance se mesurait en Mhz, de meme que la puissance d'un moteur se mesure en chevaux.
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.
-
-
[^]Re: AMD et INTEL optent pour des technologies opposées.
Posté par matiasf () le 03/01/2003 à 12:43. (lien). Évalué à 3.Pour les moteurs tu compares la puissance et non les régimes de rotation des moteurs. Sinon les diesel seraient toujours battu par les essences :-)
-
[^]Re: AMD et INTEL optent pour des technologies opposées.
Posté par kesako () le 03/01/2003 à 12:58. (lien). Évalué à 5.tss tss ... !
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 (page perso, ) le 03/01/2003 à 13:17. (lien). Évalué à 2.Tu peux aussi comparer la consommation, ou plein d'autres choses. Parce que de très nombreuses personnes n'en ont rien à foutre de la puissance de leur bagnole (qui n'est qu'un moyen de transport sur des routes soumises à des limitations de vitesse assez stricte). Pour un PC, la puissance est beaucoup plus utile que pour une voiture.
-
[^]Re: AMD et INTEL optent pour des technologies opposées.
Posté par matiasf () le 03/01/2003 à 14:01. (lien). Évalué à 1.> qui n'est qu'un moyen de transport
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 () le 03/01/2003 à 15:09. (lien). Évalué à 2.vi c'est sur...j'ai monté un Pentium 1 à 75 Mhz avec 64 Mo de Ram pour que ma soeur puisse taper ses cours...et elle à aucun problème (d'accord c'est une Lycoris Desktop que je lui ai mise)....là elle me parle de vouloir faire du jeu avec, effectivement, là ca va plu....tout est une question de rapport besoin / moyen... tu irais à l'h^opital pour une simple égratinure??? Non??? ben c'est un peu comme si tu prenais une b^ete de course pour surfer sur le ouaibe....
Voilà...-
[^]Re: AMD et INTEL optent pour des technologies opposées.
Posté par Gniarf () le 04/01/2003 à 03:16. (lien). Évalué à 2.elle veut des jeux modernes, du genre qu'on voit à la FNAC de nos jours, nuance.
un bon vieux Doom marche très bien sur ces engins-là.--
Windows has no users. It has hostages.-
[^]Re: AMD et INTEL optent pour des technologies opposées.
Posté par wismerhill (page perso, ) le 04/01/2003 à 12:17. (lien). Évalué à 2.Y a pas que les FPS comme jeux, freeciv par exemple n'a pas besoin d'un machine énorme (d'autant que dans ce type de jeux au tour par tour on peut plus facilement se permettre d'attendre un peu, ça donne du temps pour réfléchir à sa stratégie) et peut t'occuper pendant de longues heures (y a juste que son architecture client/serveur sera un peu plus difficile à apréhender pour elle).
-
[^]Re: AMD et INTEL optent pour des technologies opposées.
-
-
-
-
-
[^]Re: AMD et INTEL optent pour des technologies opposées.
Posté par gnap gnap (page perso, ) le 03/01/2003 à 14:45. (lien). Évalué à 1.Pour pousser l'analogie, il faudrait dire que la puissance brute du processeur n'est qu'un point, qu'il faut aussi compter sur la RAM, une bonne carte graphique, un écran grand, un clavier agréable... Tu dis que la puissance est très utile pour un PC, mais à Noel, je n'ai rencontré personne capable de me dire à quelle est la « puissance » (en fait, fréquence du processeur) de leur ordi. Parce que « de très nombreuses personnes n'en ont rien à foutre de la puissance de leur » ordi tant que leurs programmes marchent.
-
[^]Re: AMD et INTEL optent pour des technologies opposées.
-
-
-
[^]Re: AMD et INTEL optent pour des technologies opposées.
Posté par Serge Rossi (page perso, ) le 03/01/2003 à 13:50. (lien). Évalué à 1.Pas suffisant le couple. Faut comparer sur quelle plage de régime tu as le couple maxi disponible. Un moteur qui a 30 mkg de dispo sur 500 tours/min (et rien autour), ça n'a rien à voir avec un moteur qui à 30 mkg dispos sur une plage de 3000 tours/min ! Au final, on en revient à la valeur de puissance quand même.
-
[^]Re: AMD et INTEL optent pour des technologies opposées.
Posté par matiasf () le 03/01/2003 à 13:52. (lien). Évalué à 2.> faut comparer le couple !
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 () le 03/01/2003 à 14:38. (lien). Évalué à 1.Certe mais tes moteurs à mazout utilisent l'injection direct + un turbo, met sa sur un moteur essence et paf 40 kW de plus...
-
[^]Re: AMD et INTEL optent pour des technologies opposées.
Posté par Olivier Jeannet () le 03/01/2003 à 15:52. (lien). Évalué à 1.Certes mais tes moteurs à mazout utilisent l'injection directe + un turbo, mets ça sur un moteur essence et paf 40 kW de plus...
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 () le 03/01/2003 à 16:13. (lien). Évalué à 3.Le problème des moteurs essences est qu'ils ont un moins bon rendement à mi-charge (lorsqu'on n'est pas pied au planché).
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 Yves Dessertine (page perso, ) le 03/01/2003 à 14:15. (lien). Évalué à 3.> tss tss ... !
> 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 Rin Jin (page perso, ) le 03/01/2003 à 11:57. (lien). Évalué à 12.Le consommateur moyen,si on lui dit que le p4 accélére internet, il le croit (j'éxagére un peu, ok).
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.--
"On obtient plus de chose en étant poli et armé qu'en étant juste poli" Al Capone-
[^]Re: AMD et INTEL optent pour des technologies opposées.
Posté par philip () le 03/01/2003 à 13:20. (lien). Évalué à 3.>Le consommateur moyen,si on lui dit que le p4 accélére internet, il le croit (j'éxagére un peu, ok).
et alors c'est pas vrai ?
->[]-
[^]Re: AMD et INTEL optent pour des technologies opposées.
Posté par pfrenard () le 04/01/2003 à 12:31. (lien). Évalué à 1.Ben ....
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.
Ca fait longtemps que cette echelle de puissance devrait etre enterree. Elle n'apporte que du negatif a l'heure actuelle, dernier exemple: l'archi P4 plus lente que l'archi P3 a frequence egale, mais qui supporte plus facilement de plus hautes frequences... J'aurais prefere un P4 plus lent mais plus optimise. (pour les autres, j'en ai meme pas de P4)
A quand un rating basé sur SPECint ou autre ? Ca ferait du bien aux archis alternatives en plus =)
Votez contre le cinéma sur DLFP: http://linuxfr.org/tracker/296.html
Le lien pour voter est en haut à droite.
-
[^]Re: AMD et INTEL optent pour des technologies opposées.
Posté par Richard Van Den Boom () le 03/01/2003 à 11:31. (lien). Évalué à 12.Assez douteux, puisque le P4 et l'AXP ont parmi les meilleurs performances, sinon les meilleurs performances en SpecINT. Les seuls éventuels concurrents sont les Power d'IBM, à un prix défiant toute concurrence (vers le haut...:-)).
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 () le 03/01/2003 à 12:35. (lien). Évalué à 13.Malheureusement, le problème est dans la comparaison elle-même !
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 () le 03/01/2003 à 12:39. (lien). Évalué à 7.Et vive l'open source qui permet de recompiler à l'envie...
-
[^]Re: AMD et INTEL optent pour des technologies opposées.
Posté par Arachne (page perso, ) le 03/01/2003 à 14:00. (lien). Évalué à 2.Et vive la gentoo qui fait ça en une nuit :)
-
-
-
-
[^]Re: AMD et INTEL optent pour des technologies opposées.
Posté par reno () le 03/01/2003 à 19:51. (lien). Évalué à 4.> J'aurais prefere un P4 plus lent mais plus optimise.
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.
Pour aider le consommateur, ils soutiennent tous les deux TCPA/Palladium...
Re: AMD et INTEL optent pour des technologies opposées.
N'y aurait-il pas une inversion CISC <-> RISC dans le paragraphe "Les méthodes de mesures classiques" partie "Le MIPS" ?
-
[^]Re: AMD et INTEL optent pour des technologies opposées.
-
[^]Re: AMD et INTEL optent pour des technologies opposées.
Posté par Gaétan RYCKEBOER (page perso, ) le 03/01/2003 à 12:44. (lien). Évalué à 7.Ce n'est pas parce qu'il faut une instruction pour faire une opération que cela prend un cycle.
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 () le 03/01/2003 à 13:18. (lien). Évalué à 0.Ce n'est pas parce qu'il faut une instruction pour faire une opération que cela prend un cycle.
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 !-
[^]Re: AMD et INTEL optent pour des technologies opposées.
Posté par Moby-Dik () le 03/01/2003 à 13:31. (lien). Évalué à 1.C'est généralement vrai en RISC. C'est plus rarement vrai en CISC.
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 () le 03/01/2003 à 13:35. (lien). Évalué à 2.Je ne réponds pas de tout ce qui est fait dans le f-cpu :)
Mais tu as mal lu, il est question de latence de pipeline !!!! L'addition se fera toujours en un cycle.
-
-
-
[^]Re: AMD et INTEL optent pour des technologies opposées.
Posté par gege (page perso, ) le 03/01/2003 à 14:36. (lien). Évalué à 1.sisi ! le dernier chapitre avant la conclusion ! (c'est juste histoire de pinailler).
-
-
N'importe quoi
Vraiment n'importe quoi cet article. Bourré de fautes d'orthographe, d'approximations et de contre-sens. L'exemple qui tue : En effet, les dernières puces (P4) d'Intel on été réduites par leurs nombre d'instructions tandis que AMD as enrichi ses Athlons de dizaines de nouvelles intstuructions! Faudra qu'on m'explique comment le P4 peut être compatible avec ses prédécesseurs tout en ayant moins d'instructions, hein ;)
Poubelle.
-
[^]Re: N'importe quoi
Posté par Nicolas Boulay () le 03/01/2003 à 11:53. (lien). Évalué à 8.Je confirme.
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)!
-
[^]Re: N'importe quoi
Posté par Tom Debruyne (page perso, ) le 03/01/2003 à 12:05. (lien). Évalué à 7.Tu es un peu dur mais c'est vrai que cet article manque de finition :
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 (page perso, ) le 03/01/2003 à 12:34. (lien). Évalué à 2.* Le pourtant est lié au "ne ... plus", car il fut un temps ou les RISCs étaient les plus rapides.
* 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 () le 03/01/2003 à 12:50. (lien). Évalué à 8.>il fut un temps ou les RISCs étaient les plus rapides.
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 () le 03/01/2003 à 13:01. (lien). Évalué à 4.les processeurs x86 ont un coeur RISC et un front-end pour les instructions CISC x86
ç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).-
[^]Re: N'importe quoi
Posté par Schwarzy () le 03/01/2003 à 13:47. (lien). Évalué à 2.> C'est l'ISA qui est CISC pas le processeur
> 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 () le 03/01/2003 à 14:50. (lien). Évalué à 1.Et le but originel de faire un ISA simplifié n'était-il pas de faire une microarchitecture plus légère ?
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.
-
[^]Re: N'importe quoi
Posté par Paerro Trime () le 03/01/2003 à 18:31. (lien). Évalué à 1.En fait le SIMD était déjà un sujet d'actualité pour les calculateurs il y a plus de vingt ans. Trouvable dans un numéro de "La Recherche" d'avril 1980 si mes souvenirs sont bons :)
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 () le 03/01/2003 à 20:24. (lien). Évalué à 1.> Et le but originel de faire un ISA simplifié n'était-il pas de faire une microarchitecture plus légère ?
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é.
-
-
-
[^]Re: N'importe quoi
Posté par alenvers () le 03/01/2003 à 13:05. (lien). Évalué à 3.>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.
C'est l'inverse, la simplification du nombre instructions et de leur complexité a permis de s'attarder sur des techniques d'ordonnacement, de caching, de prédiction. Dans une architecture déja complexe cela n'aurait pas été possible (ou plutot tres difficile). Une fois ces découvertes effectuées et formalisées sur les architectures simples RISC (qui par la n'était plus si simple au vu du nombre de nouveaux concepts introduits), elles ont pu être transposées vers les CISCs.
Les RISCs ont permis l'amélioration des CISCs.
PS: Il est aussi à remarquer que les archi actuelles dites RISCs partagent également maintenant certains instructions complexes des CISCs.-
[^]Re: N'importe quoi
Posté par Richard Van Den Boom () le 03/01/2003 à 13:16. (lien). Évalué à 2.L'exécution d'instructions dans le désordre a été introduite par le Pentium Pro dans le monde CISC, tandis qu'elle n'est apparue dans le monde RISC que bien plus tard, par exemple avec l'Alpha 21264 ou l'UltraSparc III.
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 () le 03/01/2003 à 13:24. (lien). Évalué à 1.L'exécution d'instructions dans le désordre a été introduite par le Pentium Pro dans le monde CISC, tandis qu'elle n'est apparue dans le monde RISC que bien plus tard, par exemple avec l'Alpha 21264 ou l'UltraSparc III.
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)-
[^]Re: N'importe quoi
Posté par Richard Van Den Boom () le 03/01/2003 à 14:36. (lien). É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.
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 () le 03/01/2003 à 14:57. (lien). Évalué à 1.Le problème est toujours d'augmenter l'ipc à même fréquence (pour le P4, ils ont choisi de pousser le SSE que d'augmenter l'IPC mais bon). Mais comment faire avec des ISA pas conçu du tout pour ça. Bah, avec des coeurs out-of-order bien complexe.
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).-
[+] [^]Re: N'importe quoi
Posté par Richard Van Den Boom () le 03/01/2003 à 16:19. (lien). Évalué à -1.>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).
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 () le 03/01/2003 à 22:17. (lien). Évalué à 1.La finesse des outils de gravure</I>
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...). :)
-
-
-
-
-
[^]Re: N'importe quoi
Posté par alenvers () le 04/01/2003 à 11:58. (lien). Évalué à 3.Tomasulo est celui qui a introduit le out of order (plutot "formalisé" car le CDC 6600 en 1964 en avait déja !) en 1967 !
R. M. Tomasulo, "An efficient algorithm for exploiting multiple arithmetic units.", IBM Journal of Research and Development,11(1): 25-33. January 1967.
http://www.cs.clemson.edu/~mark/hist.html(...)
Un petit extrait :
1960's
* CDC 6600 (1964) - single-issue, out-of-order execution in central processor
multithreading in peripheral processors
* IBM S/360 Model 91 (1967) - single-issue, out-of-order execution using Tomasulo algorithm in floating-point unit
* IBM ACS (mid to late 1960s) - proposal for a 7-way-issue superscalar processor (successor design ACS-360 was also planned to be 2-way multithreaded)
* Mike Flynn papers on multithreading (check Spring AFIPS, 1967; ONR 1969; IFIP 1971; IEEE Computer 1972; AFIPS 1972)
PS : le CDC est considéré comme un des premiers RISC
-
[^]Re: N'importe quoi
Posté par Gaël Le Mignot (page perso, ) le 04/01/2003 à 12:49. (lien). Évalué à 5.L'exécution d'instructions dans le désordre a été introduite par le Pentium Pro dans le monde CISC
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 () le 06/01/2003 à 14:14. (lien). Évalué à 0.Raaah ! Faut lire les autres commentaires avant de dire des énormité pareils !!!
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.
-
-
-
-
-
[^]Re: N'importe quoi
Posté par Tom Debruyne (page perso, ) le 03/01/2003 à 13:07. (lien). Évalué à 2.Alors dans l'article, il faudrait remplacer Pourtant, les chips CISCs ne sont plus nécessairement les plus rapides ! par Pourtant, les chips RISCs ne sont plus nécessairement les plus rapides ! , non?
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 () le 03/01/2003 à 12:37. (lien). Évalué à 10.Pourtant, les chips CISCs ne sont plus nécessairement les plus rapides !
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-
[^]Re: N'importe quoi
Posté par Duncan Idaho (Jabber id, page perso, ) le 03/01/2003 à 13:00. (lien). Évalué à 1.(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)
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 () le 03/01/2003 à 13:05. (lien). Évalué à 1.Cela dépend ce que tu prends en comptes dans les 80 % ou les 20%.
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.
-
-
[^]erreur or not ?
Posté par snurpsss () le 04/01/2003 à 10:59. (lien). Évalué à 1.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]
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 () le 06/01/2003 à 19:04. (lien). Évalué à 1.Juste quelques remarques
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.--
\_°< C01N C01N ! >°_/-
[^]Re: N'importe quoi
Posté par Nicolas Boulay () le 07/01/2003 à 09:42. (lien). Évalué à 1.Je m'a planté dans le code mais c'est l'idée qui compte :)
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).
-
-
-
Et pourquoi pas calculer au MIPS ?
Car dans ce cas les mac sont bien dans la course :)
[David:moua]
L'intérêt de la fréquence
La fréquence du processeur à quand même l'intérêt d'être un caractéristique physique du système (au même titre que la quantité de mémoire ou la taille d'un bus) et elle n'est pas ambigue. Et elle a une signification très claire pour une même architecture: si tu double la fréquence, tu double le nombre maximum d'instructions que le processeur est capable d'exécuter. Bien sur, l'utiliser pour des comparaisons d'architectures différentes est assez problématique, et conduit à des problème marketing telles que les p-rating des athlonXP ou ces cirix en leur temps.
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 () le 03/01/2003 à 13:10. (lien). Évalué à 1.Et elle a une signification très claire pour une même architecture:
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).-
[^]Re: L'intérêt de la fréquence
Posté par analogue o/ (page perso, ) le 03/01/2003 à 13:45. (lien). Évalué à 1.Bien sur que si, le processeur executera 2x plus d'instructions dans un même laps de temps...
Après, la vitesse d'execution de la babasse entiere depend de tous les autres composants, mais ca n'est pas le sujet.--
Votez contre le cinéma sur DLFP: http://linuxfr.org/tracker/296.html
Le lien pour voter est en haut à droite.
-
[^]Re: L'intérêt de la fréquence
Posté par wismerhill (page perso, ) le 03/01/2003 à 13:58. (lien). Évalué à 4.J'ai bien dis le nom maximum que le processeur peut exécuter, c'est à dire en supposant que, par un moyen quelconque (et c'est la fonctione qu'essaye de remplire les différents caches), toutes les instructions et données sont acheminées au processeurs dès que nécessaire et sans temps de latence.
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 () le 03/01/2003 à 18:22. (lien). Évalué à 1.il y a de la RDRAM 1066 avec les nouveaux P4 non ?
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 (page perso, ) le 03/01/2003 à 18:42. (lien). Évalué à 1.L'hyperthreading est juste un truc pour pouvoir utiliser des cycles qui sinon seraient perdus à attendre que la mémoire envoie ce qu'on lui demande ou qu'un périphérique réponde. Ce n'est qu'un bidouillage parmis d'autres (mémoire cache) pour compenser la elnteur relative de tout ce qui tourne autours du processeur et l'empêche d'atteindre ses performances maximum.
-
[^]Re: L'intérêt de la fréquence
Posté par Nicolas Boulay () le 03/01/2003 à 23:06. (lien). Évalué à 1.T'es vache.
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.-
[^]Juste une question ...
Posté par Jak () le 04/01/2003 à 09:00. (lien). Évalué à 1.La technologie HyperThreading du P4 peut-elle être considérée comme une technologie SMT ?
--
« Le savoir, n'est-ce pas, est un bien précieux. Trop précieux pour ne pas être partagé. »
- Battologio d'Epanalepse, in De Cape et de Crocs, Acte VII (Ayroles & Masbou)-
[^]Re: Juste une question ...
-
[^]Re: Juste une question ...
Posté par Jak () le 04/01/2003 à 14:13. (lien). Évalué à 3.Ouais, j'ai bien relu les différentes docs que j'avais à ce sujet, et c'est en effet clairement un SMT. C'est juste que je n'avais jamais vraiment fait attention à ce P4 HT en interne, j'aurais dû y penser.
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.--
« Le savoir, n'est-ce pas, est un bien précieux. Trop précieux pour ne pas être partagé. »
- Battologio d'Epanalepse, in De Cape et de Crocs, Acte VII (Ayroles & Masbou)-
[^]Re: Juste une question ...
Posté par Paerro Trime () le 04/01/2003 à 16:38. (lien). Évalué à 2.N'empêche que pour faire du SMT, le profil du mauvais candidat, c'est quand même le processeur dont on aurait allégé le nombre d'unités d'executions pour atteindre des fréquences de ouf et qui dispose d'une quantité assez modeste de cache on-die :) On attend avec impatience de voir ce que ça va donner, vers Noël prochain je crois, sur le successeur d'un processeur bi-core, connu pour son large IPC et sa quantité respectable de cache - et actuellement fabriqué par un pachyderme du secteur (et dont le nom bizarrement commence par la même lettre et finit par le même chiffre que le processeur dont il était question au début :o) ) D'ailleurs s'ils restent sur du bi-core, ça fera deux qui feront semblant d'être quatres. Encore un petit effort et ça rappellera un sketch de Coluche... :)
-
-
-
-
-
-
-
Une nouvelle mesure: MLCPS
Le Million de Linux Compilés Par Seconde !
Ç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 () le 03/01/2003 à 13:26. (lien). Évalué à 2.C'est un très bon bench !
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.
-
[^]Re: Une nouvelle mesure: MLCPS
Posté par Gaétan RYCKEBOER (page perso, ) le 03/01/2003 à 13:29. (lien). Évalué à 1.Alors c'est le million de secondes passées à compiler linux ;-)
Sinon, t'as même pas le temps de le faire, le café.-
[^]Re: Une nouvelle mesure: MLCPS
Posté par wismerhill (page perso, ) le 03/01/2003 à 14:02. (lien). Évalué à 3.Non, faut que ce soit l'inverse d'un temps de compilation, sinon un processeur plus rapide à un chiffre plus petit, ça fait pas vendeur.
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 () le 03/01/2003 à 14:45. (lien). Évalué à 1.bah en fait, non.
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.-
[^]Re: Une nouvelle mesure: MLCPS
Posté par wismerhill (page perso, ) le 03/01/2003 à 14:56. (lien). Évalué à 1.Et il faut aussi préciser exactement les options choisie pour le noyau (à moins qu'il ne soit question d'un noyau complet et monolithique, mais n'y aurait-il pas certaines incompatibilités?).
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.
En tous les cas, si vous hésitez sur le CPU à choisir pour monter votre nouvelle machine Linux, lisez ce petit comparatif :
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/ (page perso, ) le 03/01/2003 à 14:24. (lien). Évalué à 2.Bof, a monter une nouvelle machine je prefere prendre du PowerPC.
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 =)--
Votez contre le cinéma sur DLFP: http://linuxfr.org/tracker/296.html
Le lien pour voter est en haut à droite.-
[^]Re: AMD et INTEL optent pour des technologies opposées.
Posté par Richard Van Den Boom () le 03/01/2003 à 14:45. (lien). Évalué à 1.Et c'est quoi le prix de la bête?
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 () le 03/01/2003 à 14:51. (lien). Évalué à 2.http://www.pegasos-france.com/pegcm.html(...) : 649euro pour G3 600Mhz et CM
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/ (page perso, ) le 03/01/2003 à 15:42. (lien). Évalué à 1.Je suppose que y a un ventilo, vu que dans mon CoinCoin y en a un.
--
Votez contre le cinéma sur DLFP: http://linuxfr.org/tracker/296.html
Le lien pour voter est en haut à droite.
-
[^]Re: AMD et INTEL optent pour des technologies opposées.
Posté par Richard Van Den Boom () le 03/01/2003 à 16:27. (lien). Évalué à 3.A comparer au 270 euros d'un AXP 2000+ et d'une carte Asustek nForce2.
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/ (page perso, ) le 03/01/2003 à 23:26. (lien). Évalué à 1.Je peux te comprendre pour le prix, mais pour la compatibilité ?
--
Votez contre le cinéma sur DLFP: http://linuxfr.org/tracker/296.html
Le lien pour voter est en haut à droite.
-
-
[^]Re: AMD et INTEL optent pour des technologies opposées.
Posté par Tony Cheneau () le 04/01/2003 à 13:15. (lien). Évalué à 2.J'ai un ibook2 et je sais qu'il n'y a pas de ventilo, donc, ce qui fait le plus de bruit c'est la rotation du disque dur ;)
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.
-
-
-
-
-
[^]Re: AMD et INTEL optent pour des technologies opposées.
Posté par Mathieu Pillard (page perso, ) le 03/01/2003
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.