Utilisateur:Poil/CISC
J'aimerais une explication sur la modification à la hache de l'article CISC.
- Je vous engage a lire la litterature en rapport avec l'architecture des ordinateurs. J'ai precise dans mon commentaire que j'avais supprime les conneries dans cet article. Si un des points supprimes ne vous satisfait pas, dites moi lequel - avec si possible une reference ou un argumentation - et je vous repondrais. Si vous pouviez par exemple m'expliquer ce qui s'est passe entre 1970 et 2000 en terme de rapport vitesse CPU/temps d'acces RAM, afin de justifier le second et le dernier paragraphe, ca serait un debut... Cela dit j'ai toujours un probleme avec cette histoire de I-cache : depuis 1973, et confirme avec l'apparition des RISC, on sait qu'il n'y a pas de relation entre la compacite du code et le temps d'execution d'un programme (comprendre : des architectures dont le code est N fois plus large que d'autres executent des programme beaucoup plus vite... les exemples premiers exemples datent de 1973, les RISC ont reaffirme ce effet dans les annees 1980). Stéphane 1 jun 2005 à 23:24 (CEST)
- Il me semblait bien que vous ne maitrisez pas trop le sujet. Il aurait plus élégant de commencer une discussion au lieu de tout enlever. (ps: je suis microelectronicien et j'ai déjà participer à la conception de cpu)
- Dans ce cas, vous avez sans doute les elements pour etayer vos dires. Je compte sur vous pour trouver les references qui etayeront sans failles vos arguments (que j'espere vous presenterez un jour). Stéphane 2 jun 2005 à 22:28 (CEST)
- J'abonde dans le sens de Stéphane, j'attends avec impatience vos arguments/références/sources qui donneraient du poids à des supputations hasardeuses, visiblement empreintes d'un amateurisme hésitant et brouillon.
- Ok, avant même de commencer la moindre discussion, on arrive déjà aux attaques personnels. Je crois que j'ai autre chose à faire que perdre mon temps avec vous en cherchant des "preuves" de la lenteur d'acces des RAM de l'époque. En 2 minute de google : http://ed-thelen.org/comp-hist/cdc6600.html , un descriptif du CDC 6600 de 1965-1970, avec un temps d'acces RAM de 475ns (4.75 fois plus lent que le cpu lui-même). Il faut se rappeler que le principe des mémoires caches n'étaient pas encore utilisé.
- Concernant le point des "attaques personnelles", et si vous faite référence à la remarque précedent la votre, vous constaterez que je n'en suis pas l'auteur. Plaigniez vous à qui de droit. Sur le second point, et si vous vous interessez au CDC 6600, une machine de la classe des superordinateurs, donc pionniere et digne d'interet, je peux vous faire parvenir l'article de James E. Thorton, "Parallel operation in the Control Data 6600", AFIPS Proceedings, pt. 2. vol 26, 1964, pp 33-40. Basé sur la description de cette machine, vous déduisez un écart non négligeable entre la vitesse du/des processeurs et le temps d'acces de la memoire, en faveur du CPU. Je n'ai jamais nié cela. L'article 'cisc' original disait cela aussi en une phrase, au debut. Par contre il dit aussi que ceci est un facteur (sinon le facteur) qui est a la base de la mise en place de jeux d'instructions complexes avec de nombreux modes d'adressages. Cette relation de cause a effet est fausse. Secondo : a la fin de l'article CISC, et il est affirme que nous serions retombé dans le même cas (cpu rapide, RAM lente), laissant entendre qu'entre nos ancêtres les 6600 et les POWER5 d'aujourd'hui la tendance s'était inversée à un moment donné. À vous donc de démontrer qu'a un moment donné la RAM était plus rapide que les CPU. Le plus compliqué me semble d'argumenter l'enchainement des 3 dernieres phrases de l'article : 30 ans après leur création, on retombe dans les mêmes problèmes techniques qu'à l'époque : les mémoires sont bien plus lentes que les processeurs. Les solutions d'alors sont redevenues plus intéressantes que le RISC. Aujourd'hui, les processeurs de jeu d'instruction CISC, décomposent chaque instruction en micro-instructions qui sont pipelinables. Ce qui enlève le dernier gros avantage au RISC. Ces dernieres phrases sont un verbiage sans sens, denonce par le precedent contributeur dont les reproches etaient à l'adresse de l'article CISC, pas a votre prose. Ne soyez pas parano. Stéphane 6 jun 2005 à 23:12 (CEST) (tiens, l'article de Thornton est dans les pages de Gordon Bell, http://research.microsoft.com/~gbell/Computer_Structures__Readings_and_Examples/contents.html chapitre 39. Dans le bouquin que j'ai sous les yeux, c'est le chapitre 43 pp 730 :-) Par contre le bon article semble etre J. E. Thornton. Design of a Computer-The Control Data 6600. Scott, Foresman, Glenview, II1., 1970. je vais bien le trouver sur acm ou ieee...). Stéphane
- Je faisais référence à "supputations hasardeuses, visiblement empreintes d'un amateurisme hésitant et brouillon." qui n'est pas de vous certe.
- non seulement ce n'est pas de moi, mais cela s'adresse à l'auteur des phrases supprimées de CISC. J'ignore si elle sont de vous ou pas, peu importe.
- C'était de moi...
- non seulement ce n'est pas de moi, mais cela s'adresse à l'auteur des phrases supprimées de CISC. J'ignore si elle sont de vous ou pas, peu importe.
- Je faisais référence à "supputations hasardeuses, visiblement empreintes d'un amateurisme hésitant et brouillon." qui n'est pas de vous certe.
- Concernant le point des "attaques personnelles", et si vous faite référence à la remarque précedent la votre, vous constaterez que je n'en suis pas l'auteur. Plaigniez vous à qui de droit. Sur le second point, et si vous vous interessez au CDC 6600, une machine de la classe des superordinateurs, donc pionniere et digne d'interet, je peux vous faire parvenir l'article de James E. Thorton, "Parallel operation in the Control Data 6600", AFIPS Proceedings, pt. 2. vol 26, 1964, pp 33-40. Basé sur la description de cette machine, vous déduisez un écart non négligeable entre la vitesse du/des processeurs et le temps d'acces de la memoire, en faveur du CPU. Je n'ai jamais nié cela. L'article 'cisc' original disait cela aussi en une phrase, au debut. Par contre il dit aussi que ceci est un facteur (sinon le facteur) qui est a la base de la mise en place de jeux d'instructions complexes avec de nombreux modes d'adressages. Cette relation de cause a effet est fausse. Secondo : a la fin de l'article CISC, et il est affirme que nous serions retombé dans le même cas (cpu rapide, RAM lente), laissant entendre qu'entre nos ancêtres les 6600 et les POWER5 d'aujourd'hui la tendance s'était inversée à un moment donné. À vous donc de démontrer qu'a un moment donné la RAM était plus rapide que les CPU. Le plus compliqué me semble d'argumenter l'enchainement des 3 dernieres phrases de l'article : 30 ans après leur création, on retombe dans les mêmes problèmes techniques qu'à l'époque : les mémoires sont bien plus lentes que les processeurs. Les solutions d'alors sont redevenues plus intéressantes que le RISC. Aujourd'hui, les processeurs de jeu d'instruction CISC, décomposent chaque instruction en micro-instructions qui sont pipelinables. Ce qui enlève le dernier gros avantage au RISC. Ces dernieres phrases sont un verbiage sans sens, denonce par le precedent contributeur dont les reproches etaient à l'adresse de l'article CISC, pas a votre prose. Ne soyez pas parano. Stéphane 6 jun 2005 à 23:12 (CEST) (tiens, l'article de Thornton est dans les pages de Gordon Bell, http://research.microsoft.com/~gbell/Computer_Structures__Readings_and_Examples/contents.html chapitre 39. Dans le bouquin que j'ai sous les yeux, c'est le chapitre 43 pp 730 :-) Par contre le bon article semble etre J. E. Thornton. Design of a Computer-The Control Data 6600. Scott, Foresman, Glenview, II1., 1970. je vais bien le trouver sur acm ou ieee...). Stéphane
- Ok, avant même de commencer la moindre discussion, on arrive déjà aux attaques personnels. Je crois que j'ai autre chose à faire que perdre mon temps avec vous en cherchant des "preuves" de la lenteur d'acces des RAM de l'époque. En 2 minute de google : http://ed-thelen.org/comp-hist/cdc6600.html , un descriptif du CDC 6600 de 1965-1970, avec un temps d'acces RAM de 475ns (4.75 fois plus lent que le cpu lui-même). Il faut se rappeler que le principe des mémoires caches n'étaient pas encore utilisé.
- J'abonde dans le sens de Stéphane, j'attends avec impatience vos arguments/références/sources qui donneraient du poids à des supputations hasardeuses, visiblement empreintes d'un amateurisme hésitant et brouillon.
- Dans ce cas, vous avez sans doute les elements pour etayer vos dires. Je compte sur vous pour trouver les references qui etayeront sans failles vos arguments (que j'espere vous presenterez un jour). Stéphane 2 jun 2005 à 22:28 (CEST)
- Il me semblait bien que vous ne maitrisez pas trop le sujet. Il aurait plus élégant de commencer une discussion au lieu de tout enlever. (ps: je suis microelectronicien et j'ai déjà participer à la conception de cpu)
- La RAM et le cpu ont eu une vitesse égal entre l'arrivé des risc (début 80) et celui du 486/pentium.
- http://faqaboss.sunhelp.org/ les premieres stations Sun. Pas debut 1980, le PC/RT, un des premiers RISC date de 1986. Les premiers RISC : SPARC/MIPS/PC-RT (je dois en oublier).
- La RAM et le cpu ont eu une vitesse égal entre l'arrivé des risc (début 80) et celui du 486/pentium.
- Le 486DX66 avec une fréquence de bus divisé par 2. Les premiers pentium à 66 Mhz tournait à cette vitesse pour accéder à la mémoire.
- Donc pentium @66Mhz. Cela implique temps d'acces 1/66 1= 15 ns. Un RISC a 66 Mhz a besoin d'un temps d'acces RAM a 15 ns, pour que le rapport soit 1/1 n'est ce pas ?
- Le 486DX66 avec une fréquence de bus divisé par 2. Les premiers pentium à 66 Mhz tournait à cette vitesse pour accéder à la mémoire.
- Cela correspond à l'arrivé de la DRAM. A cette époque les temps d'acces sont tombé à 60/100 ns (uniquement le cycle au niveau de la DRAM), aujourd'hui, on doit être péniblement à 10ns. Alors que les cpus sont passé de 100 à 3000 Ghz.
- 100ns de temps d'acces => frequence de 1/100 = 10 Mz non ? Rapport 1/1 cpu/ram.
- En très gros oui, mais en très gros seulement. Il y a une différence entre la vitesse de transmission avec la mémoire et le temps d'acces. Par exemple, la SDRAM utilise une interface multiplexé. La structure de son interface permet de donné dans le meilleur des cas, une donnée par cycle d'horloge. Par contre, entre le moment où le cpu demande la donnée et il la reçoit il peut s'écouler beaucoup plus de temps (4 à 8 cycles selon les SDRAM). C'est le temps de d'acces. Les DRAM asynchrone (DRAM EDO) ont le même genre de cycle.
- 100ns de temps d'acces => frequence de 1/100 = 10 Mz non ? Rapport 1/1 cpu/ram.
- Cela correspond à l'arrivé de la DRAM. A cette époque les temps d'acces sont tombé à 60/100 ns (uniquement le cycle au niveau de la DRAM), aujourd'hui, on doit être péniblement à 10ns. Alors que les cpus sont passé de 100 à 3000 Ghz.
- Ma conclusion sans doute un peu rapide, voulait faire remarquer que l'on retombait dans les mêmes soucis qui existait à l'époque de la création des CISC.
- Lesquels soucis - je parle de ceux qui auraient disparus et reaparus - ?
- Année 70 : ROM bien plus rapide que les RAM, notament à cause de l'absence de mémoire cache. Ensuite, la mémoire a rattraper les cpu en terme de vitesse avec les DRAM. Puis cela dérivé de nouveau. Il est amusant de voir que les temps d'acces de 60 ns des vieilles sparcs sont proches des puces actuelles. Même si le temps à baisser à 20ns voir moins (je n'ai pas regarder depuis ~2ans)
- Lesquels soucis - je parle de ceux qui auraient disparus et reaparus - ?
- Ma conclusion sans doute un peu rapide, voulait faire remarquer que l'on retombait dans les mêmes soucis qui existait à l'époque de la création des CISC.
- Ensuite, j'ajoutais que le changement d'architecture faisait passer d'un pure microprogramme, à un translateur qui génère des instructions pour un autre cpu qui doit être à mi-chemin vliw/risc.
- Si je comprend bien vous comparez l'architecture d'un VAX (grosso merdo) a celle du P4 (qui par compatibilite se voit contraint de manger du code CISC. A priori c'est le seul.)
- Je ne connais pas le fonctionnement des VAX. Un P4 dispose d'un translateur de code x86 vers des µinstructions de 118 bits (de mémoire). Le fameux "trace cache" mémorise ses instructions là plutôt que le code x86. Cela permet de monter plus haut en fréquence mais j'avais des calculs qui montre que ce cache de 96Ko est équivalent à un cache de 8ko pour du code x86. D'où la plus grande efficacité des athlons pendant un temps sur le P4.
- Si je comprend bien vous comparez l'architecture d'un VAX (grosso merdo) a celle du P4 (qui par compatibilite se voit contraint de manger du code CISC. A priori c'est le seul.)
- Ensuite, j'ajoutais que le changement d'architecture faisait passer d'un pure microprogramme, à un translateur qui génère des instructions pour un autre cpu qui doit être à mi-chemin vliw/risc.
- Le fait d'utiliser un "autre" cpu à coté permetait de pipeliner facilement, et donc de contourner la principal difficulté des CISC. (Transmeta a carrément utilisé un traducteur software)
- Je ne comprend pas. Quel CPU a coté de quoi ?
- Je parlais de l'unité d'execution à mot d'instruction de taille fixe qui execute les µinstructions dans le P4.
- Je ne comprend pas. Quel CPU a coté de quoi ?
- Le fait d'utiliser un "autre" cpu à coté permetait de pipeliner facilement, et donc de contourner la principal difficulté des CISC. (Transmeta a carrément utilisé un traducteur software)
- C'est quoi la principale "difficulté" des CISC ?
- C'est ce qui a été effacer de l'article... Comme le fetcher (l'unité qui va chercher les mots d'instructions en mémoire ) ne connais pas la taille des instructions en CISC, il avale par exemple 64 bits par 64 bits. Mais il ne peut y avoir de pipeline simple à cette endroit car le prochain mots de 64 bits peut être soit la suite de l'instruction soit une nouvelles instructions.
- C'est quoi la principale "difficulté" des CISC ?
- Si vous voulez rajouter des choses a cisc je veux bien, mais je preférerais que cela soit exact, au minimum, et je dois avouer que j'ai du mal a vous suivre dans ce que je crois comprendre etre fondé sur le rapport vitesse CPU/RAM entre un certain 'avant' et 'maintenant'. Moi je vous dis que cet écart à toujours existé, sauf cas trés particulier (genre dernier modele de PDP11/70 ou toute la mémoire était considérée comme de la cache, mais c'est pas trés dur a réaliser en déterrant un CPU après quelques années et lui coller de la mémoire en techno récente).
- Beaucoup de CPU "moyen" embarqué fonctionne avec de la SRAM et peuvent se passer complètement de mémoire cache.
- Si vous voulez rajouter des choses a cisc je veux bien, mais je preférerais que cela soit exact, au minimum, et je dois avouer que j'ai du mal a vous suivre dans ce que je crois comprendre etre fondé sur le rapport vitesse CPU/RAM entre un certain 'avant' et 'maintenant'. Moi je vous dis que cet écart à toujours existé, sauf cas trés particulier (genre dernier modele de PDP11/70 ou toute la mémoire était considérée comme de la cache, mais c'est pas trés dur a réaliser en déterrant un CPU après quelques années et lui coller de la mémoire en techno récente).
Le fondement des CISC c'est : faisont du hardware proche des langages de haut niveau, ainsi on met les structures FORTRAN/COBOL/PASCAL/whatever dans le silicium, et ca ira tres vite. Une machine a poussée cet argument a son paroxisme, le PDP-10. Un autre exemple : les instructions 'business oriented' des VAX, etc. Les RISCs l'ont démoli tout ca. En tout cas je ne vois pas beaucoup de CISC dans le top500...
- Stéphane 8 jun 2005 à 02:18 (CEST)
- Tout de même, le top 500 est plein d'Opteron et de Xeon. Certe, l'itanium prends une belle place mais ce n'est pas vraiment un RISC. L'architecture POWER d'IBM fait encore tourner du s390.
- Stéphane 8 jun 2005 à 02:18 (CEST)
Je ne peux pas sans cesse reprendre toutes vos imprécisions. Vous situez les RISC début 80, ensuite vous dites que « les ROM sont bien plus rapide que les RAM (1970)», donnez un exemple, ce n'est pas ce que donne mon TTL Data Book de 1976, l'IBM s/390 version G5, tourne avec des processeurs CISC microcodés (IBM's S/390 G5 Microprocessor Design, IEEE Micro, MARCH-APRIL 1999 (Vol. 19, No. 2) pp. 12-23. Résumé : The S/390 G5, the latest generation IBM mainframe system, more than doubles the performance of its predecessor. The microprocessor used in the system is a sophisticated CISC processor that features a large cache and a very high clock frequency to achieve excellent performance. We discuss the microarchitecture of the processor followed by a description of how this processor is integrated into the system. Finally, we consider the state-of-the-art reliability and availability features that make this mainframe system unique. -- je ne crois pas me tromper en disant que la version 64 bits 1.1 Ghz n'est pas du POWER). D'un seul coup vous me dites "Il y a une différence entre la vitesse de transmission avec la mémoire et le temps d'acces.", ben oui, forcément, le temps d'accés et le débit mémoire/bus ne sont pas la même chose... Moi je jette l'éponge dans cette discussion, tant qu'elle ne se recentrera pas sur des points preçis et vérifiables. Je ne suis toujours pas convaincu que cette assertion soit exact : « Année 70 : ROM bien plus rapide que les RAM, notament à cause de l'absence de mémoire cache. Ensuite, la mémoire a rattraper les cpu en terme de vitesse avec les DRAM. Puis cela dérivé de nouveau. ». Amenez des éléments concrets. Et soyez plus clair, je ne vois pas le rapport entre "rom plus rapide que RAM parce que pas de cache" : ROM ou RAM se sont des puces, c'est a ce niveau là que ca se joue. Stéphane 15 jun 2005 à 01:56 (CEST)
- "Vous situez les RISC début 80" : création de l'idée du mips par Stanford 1981 (avec techno de l'époque donc), sortie commercial :1985,
sortie commercial du sparc : 1987 (certe plus tard).
- "ben oui, forcément, le temps d'accés et le débit mémoire/bus ne sont pas la même chose..." Tout cela pour dire que cela a sont importance quand les cpu executes une instruction par cycle horloge ou qu'il faut plusieurs cycles pour une instruction.
- "ROM ou RAM se sont des puces, c'est a ce niveau là que ca se joue" C'est surtout une téchno dont on peut faire des composants.