Crunchez vos adresses URL
|
Calculez la conso électrique de votre PC
|
Hébergez vos photos
Page 18 sur 26 PremièrePremière ... 81011121314151617181920212223242526 DernièreDernière
Affichage des résultats 511 à 540 sur 764
  1. #511
    Honteusement pompé sur RWT : A Performance Evaluation Of The Nehalem Quad-Core Processor For Scientific Computing http://www.worldscinet.com/ppl/

  2. #512
    Quelqu'un connait la date de l'annonce (disponibilité) de la plateforme Tylerburg? (Core i7 version Xeon)
    http://valid.x86-secret.com/cache/banner/313021.png

  3. #513
    Citation Envoyé par DJ_DaMS Voir le message
    Quelqu'un connait la date de l'annonce (disponibilité) de la plateforme Tylerburg? (Core i7 version Xeon)
    Oui !
    Suite à une suggestion, je vais utiliser cette signature pour des canards en manque de ranking pro. Ou des quotes idiots.

  4. #514
    Citation Envoyé par Neo_13 Voir le message
    Oui !
    Euh... bon c'est vrai que ma question était mal formulée, sorry...
    Quelle est la date de sortie de la plateforme Tylerburg?
    http://valid.x86-secret.com/cache/banner/313021.png

  5. #515
    Citation Envoyé par DJ_DaMS Voir le message
    Quelqu'un connait la date de l'annonce (disponibilité) de la plateforme Tylerburg? (Core i7 version Xeon)
    Je croyais que Tylersburg = x58... Ref : http://ark.intel.com/ProductCollecti...codeName=28106 (regarder le titre de la page ).

  6. #516
    Ah? alors quel est le petit nom de code du Core i7 à la sauce Xeon?
    http://valid.x86-secret.com/cache/banner/313021.png

  7. #517
    Citation Envoyé par DJ_DaMS Voir le message
    Ah? alors quel est le petit nom de code du Core i7 à la sauce Xeon?
    Le CPU Xeon Nehalem est le Gainestown.

  8. #518
    Citation Envoyé par DJ_DaMS Voir le message
    Euh... bon c'est vrai que ma question était mal formulée, sorry...
    Quelle est la date de sortie de la plateforme Tylerburg?
    Je sais pas.
    Mais je suis sûr que quelqu'un sait.
    Suite à une suggestion, je vais utiliser cette signature pour des canards en manque de ranking pro. Ou des quotes idiots.

  9. #519
    Citation Envoyé par Neo_13 Voir le message
    Je sais pas.
    Mais je suis sûr que quelqu'un sait.
    Ben oui, c'était pas le 3 novembre dernier ?
    J'adore jouer les idiots, le naturel me va bien

  10. #520
    Bande de sots (mais je vous aime bien quand même)

    En grattant, j'ai trouvé Q1 2009
    http://valid.x86-secret.com/cache/banner/313021.png

  11. #521
    Je crois que j'en avais déjà parlé ici (de Q1), mais j'ai aussi entendu Q2.

    Au passage, le Core i7 en utilisation audio temps réel fait des merveilles.

  12. #522
    Question bete : les registres SSEx sont-ils renommes ?

  13. #523
    Bien sur (et ce depuis le debut de SSE).
    fefe - Dillon Y'Bon

  14. #524
    Citation Envoyé par fefe Voir le message
    Bien sur (et ce depuis le debut de SSE).
    Ce qui souleve une question supplementaire : les registres SSE sont 128 bits ; sont-ils renommes en deux registres 64 bits ou bien la banque de registres physiques est-elle en 128 bits ?

    Et dans la foulee, la stack FP x87 est-elle renommee ou bien laissee toute pourrite pour punir les vilains qui l'utilisent ?

  15. #525
    Quand les registres physiques sont 64 bits tu les renommes par paire (en utilisant un bit de moins pour leur adressage), quand ils sont 128 bits tu les renommes 1 par 1. Au final ca revient au meme. Je ne me souviens plus de la liste des archis qui avaient les registres physiques de 64b de large, mais P4, core 2 et core i7 sont 128 bits physiquement.

    La stack x87 est renommee et c'est une belle merde, surtout avec certaines fameuses instructions avec 2 destinations (fxchg)
    fefe - Dillon Y'Bon

  16. #526
    Merci pour les infos :-)

  17. #527
    Citation Envoyé par fefe Voir le message
    Je ne me souviens plus de la liste des archis qui avaient les registres physiques de 64b de large
    Je dirais P6, P-M et Core (ceux éstampillés "Core" et "Core Duo")

  18. #528
    Citation Envoyé par Gabriel Voir le message
    Je dirais P6, P-M et Core (ceux éstampillés "Core" et "Core Duo")
    Tu es sur ? Tu pourrais citer une source d'info ?

  19. #529
    Exact

    http://software.intel.com/en-us/foru...4/reply/70610/

    Hi All,

    Probably late answer, but I decided to clarify it anyways as I used to get similar questions regularly. Let’s leave aside x87 legacy 80-bit Floating Point (FP) instructions as they have other differences and for clarity speak only about SIMD FP operations. I’ll refer to 64-bit FP (a.k.a. double precision or DP) operations included in SSE2, and to 32-bit (single precision or SP) available since SSE in Pentium III product.

    Pentium III (only SP supported by SSE), Pentium M based CPUs (and also Core Duo, not to confuse with Core2): have 64-bit FP MUL and ADD execution units (EU) located on two different dispatch ports. 128-bit SSE operations are being split into two 64-bit parts in front end stages before they go to OOO engine for scheduling and dispatch. Also DP MUL executed with half throughput. Thus peak throughput of FP operations you can get is 0.5 64-bit MUL + 1 64-bit ADD (4 SP or 1.5 DP FLOPS) per cycle either with packed or scalar operations for DP, vectorization for SP is required.

    P4: is a bit more complex, it has 128-bit FP MUL and FP ADD units both of which can accept either packed or scalar operation every other cycle, both ADD and MUL EUs located on same port, which can dispatch just one either ADD or MUL packed or scalar operation per cycle. So, peak FP operations throughput is 1 64-bit FP MUL + 1 64-bit FP ADD per cycle (4 SP or 2 DP FLOPS) but to achieve it _packed_ 128-bit instructions must be used. If code not vector zed then just one scalar (either ADD or MUL) FP operation can be dispatched per clock on P4, this may explain relative weakness of P4 on not vectorized FP codes, on the other hand for optimized vectorized code P4 was offering very completive FP performance.

    Core2 (all current products and Nehalem) doubled peak FP performance by adding 128-bit FP ADD and FP MUL EUs (on different ports working with 1 cycle throughput), with peak FP throughput for vectorized code of 2 64-bit MUL and 2 64-bit ADD per cycle (8 SP or 4 DP FLOPS).

    Upcoming products based on Sandy Bridge microarchitecture will once again double peak FP operations throughput by introducing 256-bit AVX instruction set, supported by microarchitecture capability to start 1 256-bit FP MUL and 1 256-bit FP ADD operations per cycle (16 SP or 8 DP FLOPS).

    Hope this helps,
    -Max
    Pour AMD: http://www.xbitlabs.com/articles/cpu...amd-k10_7.html

    En gros:
    - PII/PIII/Banias/K7/Dothan/K8/Yonah : Unites 64 bits, banc de registre physique 64 bits
    - P4: Banc de registre 128 bits, unites depipelinees, effectivement 64bit/clock chacune
    - Core2, K10, Core i7: Unites 128 bits, banc de registre 128 bits.
    - AVX (Sandy Bridge): Unites et registres 256 bits.
    Dernière modification par fefe ; 21/01/2009 à 17h39.
    fefe - Dillon Y'Bon

  20. #530
    Tout ce que je vois là-dedans ce sont des data paths. On pourrait très bien imaginer (enfin moi j'y arrive, je ne suis pas designer ) que par exemple le fait que le P4 ne puisse lancer un MUL et un ADD qu'un cycle sur deux soit lié au fait que les accès aux registres se font par paquet de 64 bits ; ou bien encore dans un pipeline on pourrait accéder 64 bits à un cycle, puis 64 autres plus tard.

    C'est peut-être du grand n'importe quoi ce que je raconte, mais la citation ne m'a pas convaincu (d'un autre côté les personnes qui disent que la banque de reg fait 64 ou 128 bits ne sont pas n'importe qui non plus...).

  21. #531
    Regarde la bande passante des load 128 bits sur le P4, ca te dira en combien d'acces la register file est ecrite (1 => RF 128 bits).

    Tu pourrais dire que le Load pourrait ecrire dans 2 registres a la fois dans le meme cycle, mais un load a 2 destinations updatees dans le meme cycle c'est tellement une mauvaise idee pour le renamer et le design du banc de registre que personne ne le ferait.

    Sinon je n'ai pas de souvenirs d'archis avec un datapath plus large que leurs registres (quand on parle des registres les plus larges de l'archi).

    Au final pour celui qui ecrit du soft que le banc de registre fasse 1 bit ou 128, ce qui compte est que la bande passante des acces est 1/cycle et que ca ne prend qu'une instruction. Tu peux verifier les manuels de reference du P4, mais j'ai assez otimise de code FP/SSE sur P4 pour m'en souvenir .

    D'ailleurs soit dit en passant le design de la FP du P4 etait assez intelligent. 1 seul port de dispatch de 128 bits par cycle, avec un mul et un add depipelines de 64bits. Au final, debit de 1 add 64 bit 1 mul 64 bit / clock, le tout avec seulement 1 port de dispatch (donc 3 ports de lecture sur le fichier de registre, 2 pour les sources de l'operation FP, 1 pour le store qui peut etre lance en parallele).

    A la meme epoque le P6 et le K7 faisaient tout avec 2 ports + 1 port pour le store (quasiment 2x plus complique, 5 ports de lecture) pour moins de perf vu que tout le SSE etait casse en 2 instructions.
    Dernière modification par fefe ; 21/01/2009 à 23h21.
    fefe - Dillon Y'Bon

  22. #532
    Citation Envoyé par fefe Voir le message
    D'ailleurs soit dit en passant le design de la FP du P4 etait assez intelligent. 1 seul port de dispatch de 128 bits par cycle, avec un mul et un add depipelines de 64bits. Au final, debit de 1 add 64 bit 1 mul 64 bit / clock, le tout avec seulement 1 port de dispatch (donc 3 ports de lecture sur le fichier de registre, 2 pour les sources de l'operation FP, 1 pour le store qui peut etre lance en parallele).
    Au fait, comment se fait-il que sur P4 le FADD x87 ait un débit de 1, alors qu'en SSE2 on ne peut lancer un ADDSD que tous les 2 cycles, comme le ADDPD?
    Pour la multiplication, les deux sont bien dépipelinées.

    Sur Core, c'est plutôt le contraire avec un FMUL tous les 2 cycles et un MULPD par cycle, ce qui ne me choque pas si c'est deux unités différentes.

  23. #533
    Explications les plus rationelles:

    Sur core 2 ce sont les memes unites, mais ta mantisse est plus large en x87 qu en SSE DP ce qui ne permet pas de faire tenir tout en 1 cycle pipeline au meme cout (ton arbre de wallace est plus large => timings plus longs) => core 2 a clairement pris l'approche de ne pas trop sacrifier pour les quelques bits de precision supplementaire.

    Pour le P4 tes instructions SSE utilisent un registre 128 bits complet qu'elles soient en packed ou non. Quand tu es en scalar sse cela revient effectivement a avoir 1/2 cycles ou ton adder n'executera rien a cause de l'occupation partielle de ton registre. En X87, tu n'as pas ce probleme de registre partiel et tu peux envoyer un add tous les cycles (mais tu ne peux rien envoyer sur le multiplier en parallele si tu en envoies 1 par cycle). Le multiplier est comme pour Core2 depipeline des que ta mantisse depasse 53 bits.
    Dernière modification par fefe ; 22/01/2009 à 14h15.
    fefe - Dillon Y'Bon

  24. #534
    Merci, je n'avais pas pensé que les bancs de registres SSE et x87 étaient séparés sur le P4.

  25. #535
    Pas physiquement separes, logiquement separes. La difference entre x87 et SSE est qu'il peut y avoir une dependance entre un packed et un scalar SSE alors qu'il n y a pas de dependance entre SSE et x87. Ca rend plus difficile l'envoi potentiel de scalar tous les cycles car il faut verifier quand meme les dependances sur la partie haute du registre. En x87 il n'y a pas ce probleme donc le scheduler pour en envoyer tous les cycles est simple. Je suppose qu'ils auraient pu faire un scheduler permettant l'envoi des add scalar tous les cycles mais ca aurait ete complexe pour pas grand chose (ou alors c'etait trop complexe pour tenir dans le temps de cycle du P4).
    fefe - Dillon Y'Bon

  26. #536
    OK, merci.

    Aller, une dernière :
    Pour le Core 2, Intel n'a pas donné un débit variable au FMUL suivant la précision définie dans le contrôle FPU. J'imagine que ça aurait été trop compliqué pour le contrôle du pipeline. (et pas parce que ça ne rapporte rien : sous Windows/VC++ la FPU est configurée par défaut en 64 bits, et avec tout le code x87 dans la nature ça doit compter...)

    Mais je vois pas vraiment pourquoi exactement. Quand je change le registre de contrôle FPU j'ai droit à un vidage complet du pipeline de toute façon, donc le CPU peut supposer qu'il connaît la précision FPU très tôt et qu'elle ne changera pas jusqu'à l'exécution?

  27. #537
    Pfff x87, tu t'engages dans un trou noir avec cette question... .

    Tu vois une difference de latence des instructions x87 en fonction de la precision toi sur un core2 (pour des instructions ou la latence est differente en SSE par ex) ? En dehors des SQRT/FDIV/trigo bien sur.

    Au final en dehors des instructions calculees par iterations successives, le x87 est essentiellement calcule en 80 bits "natif", et ce pour entre autre des histoires de retro compatibilite (et des histoires de simplicite de design a l'origine aussi): etre compatible avec des caracteristiques non specifiees, mais presentes dans les produits depuis tres longtemps. C'est d'ailleurs assez connu que de mettre un intel x86 en double precision ne donne pas systematiquement les memes resultats qu'un processeur qui ne fait que du 64bit conforme a la norme IEE754, plus precis oui, mais pas le meme resultat. Au final les clients achetant du x86 veulent le meme comportement que les generations precedentes avaient.

    En plus ca simplifie le controle du scheduler de ne pas avoir a aller lire le registre de controle FP et en ne se fiant qu'a l'opcode.

    D'ailleurs AMD a un patent la dessus: http://www.patentstorm.us/patents/72...scription.html
    fefe - Dillon Y'Bon

  28. #538
    Citation Envoyé par fefe Voir le message
    Tu vois une difference de latence des instructions x87 en fonction de la precision toi sur un core2 (pour des instructions ou la latence est differente en SSE par ex) ? En dehors des SQRT/FDIV/trigo bien sur.
    Je me plaçais dans le cas de cette hypothèse :

    Citation Envoyé par fefe Voir le message
    Explications les plus rationelles:
    Sur core 2 ce sont les memes unites, mais ta mantisse est plus large en x87 qu en SSE DP ce qui ne permet pas de faire tenir tout en 1 cycle pipeline au meme cout (ton arbre de wallace est plus large => timings plus longs) => core 2 a clairement pris l'approche de ne pas trop sacrifier pour les quelques bits de precision supplementaire.
    C'est pas moi qui l'ai dit

    Et la latence du MULPS/MULSS est à 4 cycles, contre 5 pour le MULPD/MULSD et FMUL.

    Au final en dehors des instructions calculees par iterations successives, le x87 est essentiellement calcule en 80 bits "natif", et ce pour entre autre des histoires de retro compatibilite (et des histoires de simplicite de design a l'origine aussi): etre compatible avec des caracteristiques non specifiees, mais presentes dans les produits depuis tres longtemps.
    Le comportement du x87 est totalement aberrant, certes, mais c'est plutôt bien documenté. Avec même 30 pages sur l'histoire du routage des exceptions sur le 80x87 dans l'appendice D du vol. 1 de la doc Intel.

    C'est d'ailleurs assez connu que de mettre un intel x86 en double precision ne donne pas systematiquement les memes resultats qu'un processeur qui ne fait que du 64bit conforme a la norme IEE754, plus precis oui, mais pas le meme resultat.
    Oui on en avait déjà parlé. La différence est seulement au niveau du datapath de l'exposant, qui reste dans le format étendu jusqu'à l'écriture en mémoire, et qui fait qu'on peut rater des overflows et underflows.

    Mais pour un multiplieur flottant le datapath de l'exposant est normalement pas sur le chemin critique. Même, il est certainement plus court en mode x87 qu'en mode IEEE-754 (pas de biais différents à appliquer à l'exposant suivant le format).
    Donc si on a une unité capable de faire du 80-bit x87 et du 64-bit SSE, alors elle est capable de faire du 64-bit x87 au moins aussi vite que le SSE.

    En plus ca simplifie le controle du scheduler de ne pas avoir a aller lire le registre de controle FP et en ne se fiant qu'a l'opcode.
    Certes. Mais on pourrait imaginer répliquer le bit qui va bien du registre de contrôle plus près du scheduler.

    D'ailleurs AMD a un patent la dessus: http://www.patentstorm.us/patents/72...scription.html
    Comme quoi c'est pas totalement délirant
    Pour AMD on peut comprendre qu'il cherchent à éviter de passer à chaque fois par leur multiplieur monstrueux de ~90 bits spécial division...

    Après, je comprends tout à fait qu'on cherche à oublier le x87. Moi aussi j'essaie de l'oublier mais j'en ai encore des cauchemards la nuit.
    Dernière modification par Møgluglu ; 23/01/2009 à 21h08.

  29. #539
    D'ailleurs, pour nous simple dev qui ne comprenons pas tout ce que vous avez dit, comment oublier le x87 ? Il suffit simplement de le dire au compilo (je pensais que celui-ci utilisait du SSE uniquement là ou c'était possible et rentable) ?
    J'imagine que ça ne concerne que les codeurs bas niveau et/ou dont la performance du code est un facteur critique, non ? Mais p'tet que non, on se rend pas compte à quel point l'x87 (pour ceux qui ont déjà entendu ce terme ) est un héritage bien lourd/inutile.

  30. #540
    Citation Envoyé par Møgluglu Voir le message
    Le comportement du x87 est totalement aberrant, certes, mais c'est plutôt bien documenté. Avec même 30 pages sur l'histoire du routage des exceptions sur le 80x87 dans l'appendice D du vol. 1 de la doc Intel.
    Ha ça change de la section sur les exceptions 64-bit qui contient cette unique phrase "Cette section fournit la liste des exceptions 64-bit.".
    Et je n'ai pas réussi à trouver dans ces docs Intel le comportement spécifique de mov r0,r0 qui fait du zero-extend. Je préfère la doc AMD, na !

Page 18 sur 26 PremièrePremière ... 81011121314151617181920212223242526 DernièreDernière

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
  •