AMD et INTEL optent pour des technologies opposées.

Posté par  . Modéré par Fabien Penso.
Étiquettes : aucune
0
3
jan.
2003
Matériel
AMD et Intel ont fait ces derniers mois des choix radicalement différents quant à la direction à suivre pour le développement des technologies de leurs processeurs.

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.

Aller plus loin

  • # Re: AMD et INTEL optent pour des technologies opposées.

    Posté par  . Évalué à 10.

    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  (site web personnel) . É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 =(

      • [^] # Re: AMD et INTEL optent pour des technologies opposées.

        Posté par  . É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 :

          Posté par  . Évalué à 10.

          C'est parce que c'est un consommateur moyen. :)

          -1 et je sors ...

        • [^] # Re: AMD et INTEL optent pour des technologies opposées.

          Posté par  (site web personnel) . Évalué à 10.

          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.

          Posté par  . Évalué à 3.

          Parce que Intel (ou n'importe quel marchand de CPU dont les CPU ont une fréquence plus élevée) dit "Mes processeurs sont mieux ils ont plus de Mhz". C'est du marketing.

      • [^] # Re: AMD et INTEL optent pour des technologies opposées.

        Posté par  . É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  . É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  (site web personnel) . É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  . É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  . É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.

            Posté par  (site web personnel) . É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  . É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  (site web personnel) . É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...

              "La première sécurité est la liberté"

              • [^] # Re: AMD et INTEL optent pour des technologies opposées.

                Posté par  . É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  . É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  . Évalué à 0.

              dites vous etes sûr que le bébé cloné ne s'appele pas Félicianos de la Palisse ?

              :-)

          • [^] # Re: AMD et INTEL optent pour des technologies opposées.

            Posté par  . É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  . Évalué à -2.

        Je crois pour ma part que la fréquence est équivalente à la cylindré, c'est invariable, et la puissance du moteur à la rapidité du proc

        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  (site web personnel) . Évalué à 10.

      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.

      • [^] # Re: AMD et INTEL optent pour des technologies opposées.

        Posté par  . É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  . É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.

    Posté par  (site web personnel) . Évalué à 2.

    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 =)

    • [^] # Re: AMD et INTEL optent pour des technologies opposées.

      Posté par  . Évalué à 10.

      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  . É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.

    Posté par  (site web personnel) . Évalué à 10.

    Pour aider le consommateur, ils soutiennent tous les deux TCPA/Palladium...

  • # Re: AMD et INTEL optent pour des technologies opposées.

    Posté par  . Évalué à 2.

    N'y aurait-il pas une inversion CISC <-> RISC dans le paragraphe "Les méthodes de mesures classiques" partie "Le MIPS" ?

  • # N'importe quoi

    Posté par  . Évalué à 10.

    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  (site web personnel) . É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)!

      "La première sécurité est la liberté"

    • [^] # Re: N'importe quoi

      Posté par  . É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  . É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  . É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  (site web personnel) . É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).

            "La première sécurité est la liberté"

            • [^] # Re: N'importe quoi

              Posté par  . É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  (site web personnel) . É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.

                "La première sécurité est la liberté"

              • [^] # Re: N'importe quoi

                Posté par  . É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  . É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é.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 3.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: N'importe quoi

              Posté par  . É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  (site web personnel) . É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)

                "La première sécurité est la liberté"

                • [^] # Re: N'importe quoi

                  Posté par  . É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  (site web personnel) . É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).

                    "La première sécurité est la liberté"

                    • [^] # Re: N'importe quoi

                      Posté par  . É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  (site web personnel) . É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...). :)

                        "La première sécurité est la liberté"

              • [^] # Commentaire supprimé

                Posté par  . Évalué à 3.

                Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Re: N'importe quoi

                Posté par  . É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  (site web personnel) . É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.

                  "La première sécurité est la liberté"

        • [^] # Re: N'importe quoi

          Posté par  . É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  (site web personnel) . É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

        "La première sécurité est la liberté"

        • [^] # Re: N'importe quoi

          Posté par  . É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  (site web personnel) . É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.

            "La première sécurité est la liberté"

        • [^] # erreur or not ?

          Posté par  . É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  . É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.

          • [^] # Re: N'importe quoi

            Posté par  (site web personnel) . É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).

            "La première sécurité est la liberté"

  • # Et pourquoi pas calculer au MIPS ?

    Posté par  (site web personnel) . Évalué à 2.

    Car dans ce cas les mac sont bien dans la course :)

  • # L'intérêt de la fréquence

    Posté par  . Évalué à 3.

    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  (site web personnel) . É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).

      "La première sécurité est la liberté"

      • [^] # Re: L'intérêt de la fréquence

        Posté par  (site web personnel) . É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.

      • [^] # Re: L'intérêt de la fréquence

        Posté par  . É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  . É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  . É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  (site web personnel) . É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.

            "La première sécurité est la liberté"

            • [^] # Juste une question ...

              Posté par  . Évalué à 1.

              La technologie HyperThreading du P4 peut-elle être considérée comme une technologie SMT ?

              • [^] # Re: Juste une question ...

                Posté par  (site web personnel) . Évalué à 1.

                C'est un SMT !

                "La première sécurité est la liberté"

                • [^] # Re: Juste une question ...

                  Posté par  . É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.

                  • [^] # Re: Juste une question ...

                    Posté par  . É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

    Posté par  . Évalué à 8.

    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  (site web personnel) . É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.

      "La première sécurité est la liberté"

    • [^] # Re: Une nouvelle mesure: MLCPS

      Posté par  . É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  . É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  (site web personnel) . É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.

          "La première sécurité est la liberté"

          • [^] # Re: Une nouvelle mesure: MLCPS

            Posté par  . É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.

    Posté par  (site web personnel) . Évalué à 5.

    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  . Évalué à 2.

    moi j'aimerais juste savoir si c'est vrai qu'une division prend un cycle d'horloge sur un pentium ? (cf article)
    Je doute mais je suis pas sûr.

  • # Re: AMD et INTEL optent pour des technologies opposées.

    Posté par  . Évalué à 1.

    Si ya pas d'unité pour mesurer la performence brute, est-ce que le bench dépend pas de ce qu'on veut faire du CPU. Peut être qu'il est plus interessant d'avoir un G3 pour tel type d'utilisation; mais un P4 pour un autre type d'utilisation ?

    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  (site web personnel) . Évalué à 3.

      une fois éteind ? euh...

      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.