Crunchez vos adresses URL
|
Calculez la conso électrique de votre PC
|
Hébergez vos photos
Page 2 sur 3 PremièrePremière 123 DernièreDernière
Affichage des résultats 31 à 60 sur 85
  1. #31
    IBM annonce que les prochains Power vont tourner à 4GHz. Ca me semble beaucoup vu les précédents Power. Vous en pensez quoi ?
    "si tout le monde s'etait dit "pour quoi faire ?" je pense qu'on tournerait encore sur 8086. Si tant est qu'on ait l'electricite ... " Franck@X86
    If all goes well will Dell sell Cells?
    <°)))><

  2. #32
    je vote pour effet d'annonce.
    1) les précédents PPC ne penchent pas en la faveur des 4ghz
    2) si intel a refusé, c'est pas pour rien. a moins qu'ibm ait trouvé une solution efficace qui limite l'échauffement.

    bref, j'attends de voir
    Acer TM 8215WLMi C2D T7200 (2Ghz/4mo/FSB667)/2Go DDR2 667/160Go 5400trs/X1600 256-512mo HM/15'4 WSXGA+/BT2.0+EDR/Wifi ABG/DVD Supermulti
    HP NX7000 PM1.5 (1.4 d'origine)/768mo/40go/Mobility 9200 64mo(32mo d'origine)/7K250-250Go USB2
    Barton 2800+ FANLESS héhé...uch:

  3. #33
    Ils sont si proche que ca les PPC et les Power niveau archi ?
    "si tout le monde s'etait dit "pour quoi faire ?" je pense qu'on tournerait encore sur 8086. Si tant est qu'on ait l'electricite ... " Franck@X86
    If all goes well will Dell sell Cells?
    <°)))><

  4. #34
    Normalement, c'est plus ou moins les mêmes.

    Mais bon, PowerPC, c'est très large comme classe de CPU,un 750 (G3) et un 970 (G5) n'ont pas grand chose à voir entre eux, a part le jeu d'instructions.

    Le G5 (PowerPC 970) est un dérivé du Power4, avec quelques différences : un seul core au lieu de 2 (l'original), altivec intégré pour des raisons de compatibilité (pour Apple), les caches sont différents.

    Ca m'étonne aussi que ça monte a 4Ghz, mais c'est pas illogique, le G5, dérivé du Power4, monte a 2,5ghz, donc un processeur qui a 2 générations de plus peut monter à 4Ghz, même si ça me semble bcp.

  5. #35
    Citation Envoyé par Franck@x86
    Citation Envoyé par Neo_13
    ya un article sur le pipeline qui est sorti dans la presse papier... un certain franck dans hardware mag
    Ouais ouais !!! c'est sorti samedi !! :D
    Je devient dingue la, je suis persuadé que y'avait un topic la dessus nan, avec même un shot de la couv', pas moyen de le retrouver uch:
    Bref je l'ai acheter, pas encore lu (je devrait être en train de dormir, si je commence a lire ca maintenant je vais rien comprendre).

  6. #36
    Très bon article au passage, pas toujours facile d'accès au premier coup d'oeil, mais en s'y remettant plusieurs fois on arrive à se retrouver sur ces pattes, une chose m'intrigue néanmoins, dans l'article il est fait référence au temps de latch (latch delay en anglais il me semble) d'un pipeline pour un process de lithographie donné (dans le cas présent 0.022 ns ou 22ps en 90nm), je voudrais savoir où peut on trouver cette information, j'ai pourtant chercher sur les nombreuses documentations de chez Intel sur leur site FTP notamment sur les process 65nm et 90nm ainsi que sur Google mais sans succès, où peut on trouver un récapitulatif des temps de latch pour chaque process (180,130,90,65,45nm etc...) ? Deplus cette valeur peut elle énormément varier d'un fondeur à l'autre pour un même process lithographique ?
    "We can't wait twenty years to achieve a 1000 fold increase in PlayStation performance : Moore's Law is too slow for us"
    Shin'ichi Okamoto-Chief Technical Officer Sony Computer Entertainment Corporation

  7. #37
    Citation Envoyé par PeGGaaSuSS
    Je devient dingue la, je suis persuadé que y'avait un topic la dessus nan, avec même un shot de la couv', pas moyen de le retrouver uch:
    Bref je l'ai acheter, pas encore lu (je devrait être en train de dormir, si je commence a lire ca maintenant je vais rien comprendre).
    C'est le topic Bonne Année :
    http://forum.x86-secret.com/viewtopi...=4463&start=30

  8. #38
    Citation Envoyé par EPIC
    Très bon article au passage, pas toujours facile d'accès au premier coup d'oeil, mais en s'y remettant plusieurs fois on arrive à se retrouver sur ces pattes, une chose m'intrigue néanmoins, dans l'article il est fait référence au temps de latch (latch delay en anglais il me semble) d'un pipeline pour un process de lithographie donné (dans le cas présent 0.022 ns ou 22ps en 90nm), je voudrais savoir où peut on trouver cette information, j'ai pourtant chercher sur les nombreuses documentations de chez Intel sur leur site FTP notamment sur les process 65nm et 90nm ainsi que sur Google mais sans succès, où peut on trouver un récapitulatif des temps de latch pour chaque process (180,130,90,65,45nm etc...) ? Deplus cette valeur peut elle énormément varier d'un fondeur à l'autre pour un même process lithographique ?
    J'ai eu l'info par qqu'un qui travaille chez Intel. Ce temps de latch est vraiment spécifique au processeur, j'ai pris une valeur disons plausible.

    La simu repose sur pas mal d'hypothèses, dont notamment les % d'instructions de branchements et de mémoire. Mais globalement ça donne qquechose de cohérent. Une étude Intel, beaucoup plus poussée que la mienne (encore heureux) inclut beaucoup plus de paramètres, et le max de perf est trouvé entre 50 et 55 niveaux de pipeline.

    Pour la doc, chercher dans google des publications de Sprangle, il bosse chez Intel également.

  9. #39
    Ok, merci de ces précisions :jap: ,par ailleurs j'ai pu trouver un peu par hazard ce qui pourrait être le temps de latch du pipeline du Pentium 4 Willamette (Process 180nm). Bon bien sur je ne sais pas ce que cela vaut mais il serait aux alentour de 75ps ce qui en appliquant la même méthode de calcul nous donnerait un temps de cycle du pipeline de 0.325 ns soit une fréquence de environ 3 Ghz pour cette version du pentium 4, en admettant que mon caclul soit bon, sachant que le Willamette s'est arrêté bien plutôt au niveau commercial, (il me semble aux alentour de 2 Ghz), on pourrais en conclure un certain nombre de chose :

    - Le core Willamette a eut une évolution de sa fréquence stoppé bien plutôt que prévus.

    - Le process 180 nm montrait peut-être (certainement) ces limites à partir de 2.5 Ghz (??).

    - Entre le process et la profondeur du pipeline, le premier était certainement le facteur limitant

    - Le process 130 nm du core Northwood donnait comme tu la démontré une marge de progression (dans la pratique) largement supérieur à celui du core Wilamette qui s'il avait du atteindre des fréquences avoisinant les 3 Ghz aurait du se faire en modifiant certain paramètres comme le voltage du core pour stabiliser le signal... bref plus d'emmerdes qu'autrechose pour Intel alors que le process 130 nm était prêt et n'avait que des avantages ! Le Northwood à d'ailleurs été la meilleur génération de Pentium 4 par ces performances
    "We can't wait twenty years to achieve a 1000 fold increase in PlayStation performance : Moore's Law is too slow for us"
    Shin'ichi Okamoto-Chief Technical Officer Sony Computer Entertainment Corporation

  10. #40
    ton raisonnement se tient bien.
    le williamette est allé jusqu'a 2ghz en commercial (S423 ou 478) et en aircooling y en a pas des masses qui doivent être stable au dessus de 2,3.

    Suivant ton calcul, à pipeline equivalent au williamette si je me souvient bien, les northwood ne seraient pas allé beaucoup plus loin que 3ghz (+10% = 3,4 (oui, j'ai arrondi!!!), ce qui explique qu'intel ne se soit pas contenté d'un die-shrink du northwood, ce qui aurait satisfait tout le monde (et permis d'éviter les spéculations sur les 3,4C sur ce forum...non mais!)

    j'ai bon?
    Acer TM 8215WLMi C2D T7200 (2Ghz/4mo/FSB667)/2Go DDR2 667/160Go 5400trs/X1600 256-512mo HM/15'4 WSXGA+/BT2.0+EDR/Wifi ABG/DVD Supermulti
    HP NX7000 PM1.5 (1.4 d'origine)/768mo/40go/Mobility 9200 64mo(32mo d'origine)/7K250-250Go USB2
    Barton 2800+ FANLESS héhé...uch:

  11. #41
    Y a quand même un truc que je pige pas dans la stratégie d'Intel, je n'arrive pas à croire qu'ils n'aient pas pu prévoir bien plutôt les problèmes de dégagements thermiques, car on est tous d'accord pour le dire c'est le dégagement thermique qui a tué ce processeur (si on ne tiens pas compte de la concurence bien sur).

    Donc en admettant qu'Intel connaisssait les limitations de Netburst avec le process 90nm il était facilement envisageable de concevoir un processeurs bien moins ambitieux que le Prescott et le Tejas, on conservait le pipeline de 30 niveaux (ou un peu moins) pour s'assurer une montée suffisante de la fréquence sans pour autant viser les 5 Ghz et plus de ce fait cela permettait d'avoir des caches de plus faible latences sans compromettre les très bonnes performances de l'architecture mémoire du Northwood.
    Avec seulement 1 MB et les latences de caches plus aggressives de ce dernier ajouté à cela les améliorations de la micro-architecture du Prescott (Imul,Prédiction de branchmement, etc...) On aurait eut un processeurs qui aurait je pense rivaliser bien plus facilement avec l'Athlon64...

    En fait le vrai problème du Pentium 4 c'est probablement l'architecture AMD64 qui foutu en l'air la tranquille stratégie d'Intel... car je ne suis pas sur qu'intel était prêt à passer aussi rapidement au 64 bits, d'ailleurs on ne sera jamais vraiment ce qu'était Yamhill et si cela correspondait au 40 millions de transistors en plus du Prescott...
    "We can't wait twenty years to achieve a 1000 fold increase in PlayStation performance : Moore's Law is too slow for us"
    Shin'ichi Okamoto-Chief Technical Officer Sony Computer Entertainment Corporation

  12. #42
    je pense que c'est également ces 40 millions de transistor surnuméraires qui ont fait du mal.

    on sait pas vraiment à quoi ils servent, mais ils chauffent. Si c'est un second core d'execution complet comme Sam le supposait dans son article, ça a du foirer quelque part pour qu'intel sorte le dual core avec deux cores de prescott complet (soit 4 core d'exe si on suit la meme supposition).

    Et c'est clair qu'AMD a bien joué le coup aussi, car le 64bits -toujours aussi inutile- s'est imposé comme un argument de vente important et a forcé intel à revoir ses plans. Dans le meme sens on peut supposer qu'AMD a poussé Intel a sortir une solution batarde de dual core alors qu'il aurait (attention super supposition) pu faire évoluer le prescott comme prévu à l'origine (toujours supposition) c'est a dire en rajoutant un 2e cache L2 et en activant le 2e core d'exe du prescott. (et on aurait eu 2 core avec 1mo chacun dans un seul die de prescott 2M! ...c'est beau les supposition :whistle: )
    Acer TM 8215WLMi C2D T7200 (2Ghz/4mo/FSB667)/2Go DDR2 667/160Go 5400trs/X1600 256-512mo HM/15'4 WSXGA+/BT2.0+EDR/Wifi ABG/DVD Supermulti
    HP NX7000 PM1.5 (1.4 d'origine)/768mo/40go/Mobility 9200 64mo(32mo d'origine)/7K250-250Go USB2
    Barton 2800+ FANLESS héhé...uch:

  13. #43
    Y'a jamais eu de second core caché non activé dans le Prescott !
    L'inflation du nombre de transistors vient de l'augmentation de la longueur du pipeline, ce qui a complexifié le design de certaines étapes (l'OOO notamment, comme je l'explique dans le mag).
    Avec le Prescott Intel a aussi du abandonner ses fameuses ALU "double speed", et pour obtenir la même vitesse de traitement a transformé chaque ALU 2x en deux ALUs 1x. Ce qui explique que le die montre qquechose ressemblant à deux cores, mais il ne s'agit pas de ça du tout.

    Comme je le dis dans l'article on reviendra forcément à des très longs pipelines, c'est juste une question de temps. On peut voir le P4 comme un précurseur, tout dépend du point de vue !

  14. #44
    Citation Envoyé par Franck@x86
    Avec le Prescott Intel a aussi du abandonner ses fameuses ALU "double speed", et pour obtenir la même vitesse de traitement a transformé chaque ALU 2x en deux ALUs 1x. Ce qui explique que le die montre qquechose ressemblant à deux cores, mais il ne s'agit pas de ça du tout.
    Ah, très intéressant ça, je ne le savais pas...
    Avec les militaires il y a toujours quelque chose à craindre, à moins d’être mort.

  15. #45
    Citation Envoyé par Franck@x86
    Y'a jamais eu de second core caché non activé dans le Prescott !
    L'inflation du nombre de transistors vient de l'augmentation de la longueur du pipeline, ce qui a complexifié le design de certaines étapes (l'OOO notamment, comme je l'explique dans le mag).
    Avec le Prescott Intel a aussi du abandonner ses fameuses ALU "double speed", et pour obtenir la même vitesse de traitement a transformé chaque ALU 2x en deux ALUs 1x. Ce qui explique que le die montre qquechose ressemblant à deux cores, mais il ne s'agit pas de ça du tout.

    Comme je le dis dans l'article on reviendra forcément à des très longs pipelines, c'est juste une question de temps. On peut voir le P4 comme un précurseur, tout dépend du point de vue !
    Effectivement c'est très intéressant comme information mais alors ce qui resemblait à un autre cache L1 s'était quoi ?
    "We can't wait twenty years to achieve a 1000 fold increase in PlayStation performance : Moore's Law is too slow for us"
    Shin'ichi Okamoto-Chief Technical Officer Sony Computer Entertainment Corporation

  16. #46
    Donc au final on aurait plus 3 ALUs comme sur le Northwood mais 5 ALUs ? Ce qui doit considérablement changer la donne au niveau du flux d'instructions, Intel a du revoir le Front End de son CPU pour pouvoir alimenter correctement ces ALUs, ce qui explique aussi l'augmentation du trace-cache probablement...

    Avec le Prescott, et le McKinley (Itanium 180nm) chez Intel ils sont adepte de la multiplication des ALUs...

    Sait on au moins pourquoi Intel à revue sa copie concernant les ALU double Speed ? à cause de la performance des caches ?
    "We can't wait twenty years to achieve a 1000 fold increase in PlayStation performance : Moore's Law is too slow for us"
    Shin'ichi Okamoto-Chief Technical Officer Sony Computer Entertainment Corporation

  17. #47
    Supposition sûrement stupide, mais les ALU double speed n'étaient-elles pas aussi sujettes à des problèmes de montée en fréquence?
    Avec les militaires il y a toujours quelque chose à craindre, à moins d’être mort.

  18. #48
    Citation Envoyé par Minuteman
    Supposition sûrement stupide, mais les ALU double speed n'étaient-elles pas aussi sujettes à des problèmes de montée en fréquence?
    Les ALUs elles même je ne pense pas, par contre les caches L1 qui je crois ont une latence de 1 cycle certainement... Ce qui en augmentant leur latence ne permet plus d'alimenter sufisament régulièrement les ALUs double speed et du coup fait perdre leur intéret aux ALUs 2x ... La compensation semble donc d'augmenter le nombre d'ALUs quant à la latence elle est théoriquement compensé par la taille du trace cache qui augmente mais bon rien est moins sur...
    "We can't wait twenty years to achieve a 1000 fold increase in PlayStation performance : Moore's Law is too slow for us"
    Shin'ichi Okamoto-Chief Technical Officer Sony Computer Entertainment Corporation

  19. #49
    Le trace cache a pas bougé entre le Northwood et le Prescott, c'est le L1 de données qui a doublé.

    Pour les ALUs je ne sais pas précisément, ça doit également être lié au nouveau découpage.

  20. #50
    2x Alu double speed + 1 slow Alu a la meme bande passante par cycle que 4 Alu + 1 slow alu donc je ne vois pas l'interet de changer la bande passante du frontend.

    En revanche pour comprendre l'interet de pouvoir executer 5 ALU par cycle alors que le frontend ne peut en envoyer que 3 il faut aller regarder du cote de "replay". Il y a quelques articles sur le web qui trainent et expliquent ca pas mal (en particulier un article de 30 pages qui contient pas mal d'infos de je ne sais plus quel site).
    fefe - Dillon Y'Bon

  21. #51
    Citation Envoyé par Franck@x86
    Comme je le dis dans l'article on reviendra forcément à des très longs pipelines, c'est juste une question de temps. On peut voir le P4 comme un précurseur, tout dépend du point de vue !
    Si on regarde les pipelines des GPU c'est deja le cas (il y en a eu des 100aines dans certains), pour ce qui est du retour des core a des pipelines longs dans les CPUS (cad plus que rajouter 1 ou 2 etages sur un pipeline de P6/K7) je doute que cela ne se produise si le budget power attribue au processeur reste le meme et que les techno de gravure continuent d'evoluer dans la meme direction (+ de leakage, + de RC delay n'encouragent pas a ajouter des etages de pipeline).

    La recherche de la performance single thread pousse a faire des pipelines plus profonds, l'economie d'energie pousse dans l'autre sens. A supposer que l'on reussisse la transition vers le multithread comme moyen fiable d'ameliorer les performances, la tendance deviendrait dans ce cas une multiplication des cores avec une reduction de la profondeur du pipeline.

    Si le multithread "echoue" et qu'un retour au single thread se profile, alors il n'y aura pas vraiment d'autre choix que de retourner a des pipelines plus profonds pour les CPU.

    Pour les GPU avec l'augmentation des branchements dans les shaders c'est plutot l'inverse qui se produit, mais les pipelines restent particulierement profonds car ils sont senses etre suffisament longs pour recouvrir les acces memoire (combine avec le nombre de threads).
    fefe - Dillon Y'Bon

  22. #52
    Citation Envoyé par fefe
    2x Alu double speed + 1 slow Alu a la meme bande passante par cycle que 4 Alu + 1 slow alu donc je ne vois pas l'interet de changer la bande passante du frontend.

    En revanche pour comprendre l'interet de pouvoir executer 5 ALU par cycle alors que le frontend ne peut en envoyer que 3 il faut aller regarder du cote de "replay". Il y a quelques articles sur le web qui trainent et expliquent ca pas mal (en particulier un article de 30 pages qui contient pas mal d'infos de je ne sais plus quel site).
    L'article c'est chez www.xbitlabs.com et il s'intitule "le dernier des Mohicans" et il est en deux parties de 20-30 pages chacunes + des cadeaux bonuxes.

    http://www.xbitlabs.com/articles/cpu...etburst-1.html
    http://www.xbitlabs.com/articles/cpu...etburst-2.html

    plus la partie speciale Alien :

    http://www.xbitlabs.com/articles/cpu...ay/replay.html
    "si tout le monde s'etait dit "pour quoi faire ?" je pense qu'on tournerait encore sur 8086. Si tant est qu'on ait l'electricite ... " Franck@X86
    If all goes well will Dell sell Cells?
    <°)))><

  23. #53
    Je peux me tromper mais je pense qu'un des freins actuellement à une bonne efficacité des pipelines longs c'est aussi le nombre limité de registres entiers en 32 bits.
    Avec un pipeline de 30 étages on peut théoriquement executer jusqu'a 30 instructions en parallèle (même si en pratique on a peu de chances d'atteindre ce nombre) mais comme on a que 8 registres la plupart des ces instructions se retrouvent être des NOP pour attendre qu'un registre se libère.

  24. #54
    Citation Envoyé par seb64
    Je peux me tromper mais je pense qu'un des freins actuellement à une bonne efficacité des pipelines longs c'est aussi le nombre limité de registres entiers en 32 bits.
    Avec un pipeline de 30 étages on peut théoriquement executer jusqu'a 30 instructions en parallèle (même si en pratique on a peu de chances d'atteindre ce nombre) mais comme on a que 8 registres la plupart des ces instructions se retrouvent être des NOP pour attendre qu'un registre se libère.
    Il y a beaucoup plus de registres que ca. Le programmeur n'en voit que 8 mais en interne c'est beaucoup plus et c'est le cpu qui les alloue dynamiquement. En tout cas pour les x86 récents(P2-PPro and up).
    "si tout le monde s'etait dit "pour quoi faire ?" je pense qu'on tournerait encore sur 8086. Si tant est qu'on ait l'electricite ... " Franck@X86
    If all goes well will Dell sell Cells?
    <°)))><

  25. #55
    j'avais le chiffre quelque part, mais c'est un truc genre 96 registres dans un p4... c'est l'une des raisons pour lesquels l'amd64 ne représente presque rien en transistors...
    Suite à une suggestion, je vais utiliser cette signature pour des canards en manque de ranking pro. Ou des quotes idiots.

  26. #56
    Visiblement sur P4 c'est 128 GPR et 128 FPR. Vois www.sandpile.org pour les autres archi.

    40 et 120 sur K8.
    "si tout le monde s'etait dit "pour quoi faire ?" je pense qu'on tournerait encore sur 8086. Si tant est qu'on ait l'electricite ... " Franck@X86
    If all goes well will Dell sell Cells?
    <°)))><

  27. #57
    J'ai bien fait de dire "je peux me tromper".

    Par contre le register renaming (avoir plus de registres que ce que prévoit l'architecture) ça ne date que du P4 (K7 pour AMD), avant ils utilisaient un reorder buffer (garder un historique des registres avec les valeurs à plusieurs moments) pour gérer les problèmes de manque de registres.

  28. #58
    Citation Envoyé par seb64
    J'ai bien fait de dire "je peux me tromper".
    J'aurais bien fait de le dire.
    "si tout le monde s'etait dit "pour quoi faire ?" je pense qu'on tournerait encore sur 8086. Si tant est qu'on ait l'electricite ... " Franck@X86
    If all goes well will Dell sell Cells?
    <°)))><

  29. #59
    Citation Envoyé par fefe
    Si le multithread "echoue" et qu'un retour au single thread se profile, alors il n'y aura pas vraiment d'autre choix que de retourner a des pipelines plus profonds pour les CPU.
    Je ne pense pas qu'on fera marche arrière sur le multithread.
    Maintenant, il ne faut pas que compter que sur lui pour améliorer les perfs, y a un (proche ?) moment ou ca n'apportera plus rien (sauf donner raison à Moore ?).

    Citation Envoyé par seb64
    Avec un pipeline de 30 étages on peut théoriquement executer jusqu'a 30 instructions en parallèle
    Mouais, on peut pas vraiment parler d'instructions ( != IPC)

  30. #60
    Citation Envoyé par Yasko
    Maintenant, il ne faut pas que compter que sur lui pour améliorer les perfs, y a un (proche ?) moment ou ca n'apportera plus rien (sauf donner raison à Moore ?).
    En l'occurence il ne s'agit pas de la loi de Moore mais de la loi d'Amdahl :
    Code:
    http&#58;//fr.wikipedia.org/wiki/Loi_d'Amdahl
    (~&!@# de lien)

    La courbe tend à s'aplatir avec l''augmentation du nb de CPUs, mais on peut jouer sur plusieurs paramètres, dont la proportion de code qui peut tourner de façon parallèle.

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •