Crunchez vos adresses URL
|
Calculez la conso électrique de votre PC
|
Hébergez vos photos
Page 10 sur 19 PremièrePremière ... 23456789101112131415161718 ... DernièreDernière
Affichage des résultats 271 à 300 sur 567

Discussion: Intel et Larrabee

  1. #271
    Citation Envoyé par newbie06 Voir le message
    Le premier transparent, j'ai cru qu'ils avaient pompe un slide du CELL (qui lui-meme avait du etre pompe ailleurs)
    Normal, à l'époque du Cell tout le monde repompait les schémas de Hiroshige Goto. Tu as pris ça pour une imitation alors que c'est l'original

    On a une idee de la vitesse du ring bus ?
    512 bits dans chaque sens à ~1,5 GHz, ça doit "tourner" autour de 2x100Go/s. Le crossbar du GT200 est aussi dans ces eaux-là, probablement celui du RV770 aussi (le ringbus du R600 était déjà en 2x512 bits, mais à 740 MHz).

    Il semblerait que les prochaines versions a plus de 16 cores utiliseraient des ring-bus multiples pour scaler (slides du bas).

  2. #272
    Citation Envoyé par Møgluglu Voir le message
    512 bits dans chaque sens à ~1,5 GHz, ça doit "tourner" autour de 2x100Go/s.
    C'est pas un peu leger ? Le CELL avec ses seulement 8 proc (+1 pour le PPC si cher a Fefe) monte sans probleme a 200 GB/s. Est-ce utile, je n'en sais rien, mais c'est atteignable (teste par bibi sur 6 SPU [salete de PS3]). Et la on parle bien de 48 coeurs, non ?

    De plus, le CELL utilise des DMA qui permettent de completement masquer les transferts pendant que des calculs se font. Y'a ca sur Larrabee ? Ca me parait assez indispensable (mais je ne suis pas un specialiste, loin de la).

    Il semblerait que les prochaines versions a plus de 16 cores utiliseraient des ring-bus multiples pour scaler (slides du bas).
    Je ne comprends pas ce slide comme toi (je parle du tout dernier en bas, image de droite). J'ai plutot l'impression qu'il y a toujours un double anneau, mais dont la topologie a change (ca peut aussi etre une simplification du dessin). Un bete changement de topologie reduirait la latence entre les coeurs, mais n'augmenterait pas la bande passant, si ?

  3. #273
    Citation Envoyé par newbie06 Voir le message
    C'est pas un peu leger ? Le CELL avec ses seulement 8 proc (+1 pour le PPC si cher a Fefe) monte sans probleme a 200 GB/s. Est-ce utile, je n'en sais rien, mais c'est atteignable (teste par bibi sur 6 SPU [salete de PS3]). Et la on parle bien de 48 coeurs, non ?
    Un ring bien fait (pas un bus mais des liens point a point) de 512 bits de large bidirectionnel a 1.5GHz avec on va dire au hasard 32 noeuds peut debiter 32*512*2*1.5G=49Tb/s = 6To/s ... Bien entendu c'est en peak en partant du principe que le load balancing de chaque lien est parfait et tout et tout. Mais au final meme si tu es a 25% d'utilisation ca reste un ordre de grandeur au dessus du cell...

    De plus, le CELL utilise des DMA qui permettent de completement masquer les transferts pendant que des calculs se font. Y'a ca sur Larrabee ? Ca me parait assez indispensable (mais je ne suis pas un specialiste, loin de la).
    Sur les processeurs OOO x86 c'est pris en charge par les prefetchers et les fill buffers (tant que l'OOO trouve quelque chose a executer). Vu que LRB est in-order (merci le pentium) je suis certain qu'ils ont une methode pour permettre de maintenir suffisament d'acces a la memoire en parallele. Ca peut etre un DMA, mais il y a beaucoup d'autres manieres d'y arriver.
    fefe - Dillon Y'Bon

  4. #274
    Citation Envoyé par newbie06 Voir le message
    Et la on parle bien de 48 coeurs, non ?
    Ça dépend si ta source c'est Fudzilla ou pas
    C'est plutôt 16 qui est visé au début...

    Je ne comprends pas ce slide comme toi (je parle du tout dernier en bas, image de droite). J'ai plutot l'impression qu'il y a toujours un double anneau, mais dont la topologie a change (ca peut aussi etre une simplification du dessin). Un bete changement de topologie reduirait la latence entre les coeurs, mais n'augmenterait pas la bande passant, si ?
    Ah oui j'avais pas vu les flèches.

    Mais la slide de droite a 2 coeurs de plus et un anneau de plus, c'est donc qu'il y a plus de coeurs et de bande passante non?
    Faudrait voir la slide 24.

    Mais la discussion porte surtout sur la difficulté de maintenir la cohérence des caches quand on augmente le nombre de coeurs et quand le trafic de snoop sature le ring bus. D'où les tag directories sur le dessin.

    De plus, le CELL utilise des DMA qui permettent de completement masquer les transferts pendant que des calculs se font. Y'a ca sur Larrabee ? Ca me parait assez indispensable (mais je ne suis pas un specialiste, loin de la).
    Citation Envoyé par fefe Voir le message
    Sur les processeurs OOO x86 c'est pris en charge par les prefetchers et les fill buffers (tant que l'OOO trouve quelque chose a executer). Vu que LRB est in-order (merci le pentium) je suis certain qu'ils ont une methode pour permettre de maintenir suffisament d'acces a la memoire en parallele. Ca peut etre un DMA, mais il y a beaucoup d'autres manieres d'y arriver.
    Le SMT, le SIMD et le multithreading software doivent aider pas mal aussi. (J'imagine que les loads sont asynchrones comme sur GPU, en bloquant seulement au moment de la consommation de la donnée.)
    Même si ça reste ridicule par rapport à ce que peut faire un GPU.

  5. #275
    Citation Envoyé par fefe Voir le message
    Un ring bien fait (pas un bus mais des liens point a point) de 512 bits de large bidirectionnel a 1.5GHz avec on va dire au hasard 32 noeuds peut debiter 32*512*2*1.5G=49Tb/s = 6To/s ... Bien entendu c'est en peak en partant du principe que le load balancing de chaque lien est parfait et tout et tout. Mais au final meme si tu es a 25% d'utilisation ca reste un ordre de grandeur au dessus du cell...
    Ca me parait mieux que le chiffre donne par Møgluglu

    Ca peut etre un DMA, mais il y a beaucoup d'autres manieres d'y arriver.
    Pour moi un DMA c'est juste une facon de dire qu'il y a un bidule qu'on active explicitement pour faire du transfert memoire et qui marche sans bloquer le processeur. Maintenant si tes autres manieres d'y arriver sont automatiques, j'espere pour Intel que c'est bien foutu et pas trop specialise pour un type de charge...

  6. #276
    Citation Envoyé par Møgluglu Voir le message
    Le SMT, le SIMD et le multithreading software doivent aider pas mal aussi. (J'imagine que les loads sont asynchrones comme sur GPU, en bloquant seulement au moment de la consommation de la donnée.)
    Même si ça reste ridicule par rapport à ce que peut faire un GPU.
    Sur une machine OOO:
    Le SMT peut aider, mais si ton application a 1 thread est bien ecrite... ca n'aide pas vraiment vu que les les buffers qui trackent les acces memoire en parallele sont partages (sinon maintenir la coherence serait soit lent soit cauchemardesque). Le SIMD n'aide pas vraiment non plus vu que les buffer dont je parle trackent des lignes de cache, donc que les acces aient ete genere par 1 ou 8 instructions la difference est negligeable (reduire les instructions aide l'OOO a aller plus loin dans sa recherche de parallelisme, donc ca peut aider).

    Sur une machine In Order:
    Tu ne peux pas avoir plus d'1 load en parallele vu que tu es oblige d'attendre le resultat pour rester dans l'ordre. Si tu procedes avec des instructions independantes il te faut verifier leur independance (ce que font les stations de reservation en general) et stocker leur resultat dans un buffer (ROB en general) pour mettre a jour l'etat de la machine dans l'ordre. Dans ce cas multiplier les threads aide a generer plus d'acces paralleles a la memoire (1 par thread), le SIMD par contre n'aide pas vraiment vu que la taille de la ligne de cache est generalement superieure a la largeur de ton mot SIMD.

    Pour les loads asynchrones c'est donc l'antithese d'un processeur in-order. Si tu peux faire des load (en x86 les instructions qui demarrent par mov ou ont une source en memoire) asynchrones tu es OOO sinon tu es in order. Tes prefetcheurs eux peuvent etre asynchrone par contre vu qu'ils ne modifient pas l'etat de ta machine, tu peux avoir un prefetcheur qui travaille mot par mot (software prefetch ala SSE par ex) ou stream par stream et programmable (un DMA, ou un prefetcheur ala AltiVec qui est une forme de DMA).

    Pour le nombre de cores, 48 Pentium + unites vectorielles ne tient pas dans le reticule d'une machine de prod en 45nm donc il n'y a aucun doute que le nombre de coeur est inferieur. Dans mes calculs, avec 16 il reste pas mal de place donc il n'est pas impossible qu'il y ait un peu plus de coeurs. Apres pour le nombre d'agents sur le ring, il faut ajouter les controleurs memoires (les connecter tous n 1 seul point est equivalent a creer un bottleneck en cet endroit du ring donc il est plus que probable qu'ils soient repartis histoire de maximiser la bande passante) et autres unites avec des fonctions hardware dediees au graphique qu'ils ne manqueront pas d'ajouter (et de repartir sur le ring). Au final je pense que mon 32 n'est pas une si mauvaise approximation.

    Citation Envoyé par newbie06 Voir le message
    Pour moi un DMA c'est juste une facon de dire qu'il y a un bidule qu'on active explicitement pour faire du transfert memoire et qui marche sans bloquer le processeur.
    On est d'accord.
    Dernière modification par fefe ; 25/11/2008 à 16h00. Motif: Fusion automatique
    fefe - Dillon Y'Bon

  7. #277
    D'après Wikipedia () :
    Larrabee has a 1024-bit (512-bit each way) ring bus for communication between cores and to memory.[8] This bus can be configured in two modes to support Larrabee products with 16 cores or more, or fewer than 16 cores.[10]
    Leur source : http://news.cnet.com/8301-13512_3-10006184-23.html

    Je suppose qu'ils font référence au ring bus simple et au Xring (3 rings). Mais cela veut surtout dire qu'Intel prévoit également un LRB de 16 cores ou moins.
    Par contre je n'ai pas vu le document sur lequel s'appuie CNet.

    Un pari sur le nombre de cores de LRB ? Les différentes rumeurs annoncent 16, 24, 32 voire 48 (on va oublier le 80 ). J'vote pour du 24 effectif.

  8. #278
    Citation Envoyé par Foudge Voir le message
    Je crois qu'on t'as entendu. Voici un supercalculateur basé sur des Atom sous le nom de code "Project Molecule"
    http://techon.nikkeibp.co.jp/english...081121/161590/
    SGI coiffe sur le poteau : http://www.xtremesystems.org/Forums/...d.php?t=208851

    OK, je sors...

  9. #279

  10. #280
    Citation Envoyé par Yasko Voir le message
    On dit f*ck Ballmer, parce que si c'est ca qui finira dans Larrabee, ca veut dire qu'il faudra un temps non negligeable avant de voir un driver OpenGL qui tient la route.

  11. #281
    Je ne suis pas persuadé que ça exploitera LRB si bien que ça. A mon avis, Intel sortira son driver Direct3D (et OpenGL), comme tout le monde.

  12. #282
    Citation Envoyé par newbie06 Voir le message
    On dit f*ck Ballmer, parce que si c'est ca qui finira dans Larrabee, ca veut dire qu'il faudra un temps non negligeable avant de voir un driver OpenGL qui tient la route.
    C'est quoi OpenGL ?


    Plutôt qu'un wrapper, un DX directement compilé pour LRB, ca serait envisageable ? C'est à quel moment qu'il sert x86 dans l'histoire ?

  13. #283
    Citation Envoyé par Yasko Voir le message
    Plutôt qu'un wrapper, un DX directement compilé pour LRB, ca serait envisageable ? C'est à quel moment qu'il sert x86 dans l'histoire ?
    Je pense que Doc_TB s'est un peu fourvoye en utilisant le terme "wrapper". Apparemment le bouzin utilise l'API DX10. Va voir l'article de MSDN.

  14. #284
    Vrai ou pas ? http://www.theinquirer.net/inquirer/...laystation-gpu

    Bon ptet pas finalement : http://www.techradar.com/news/gaming...rumours-525563

    Mon cote anti monopolistique voudrait que ce soit MS/Intel, Sony/nVidia et Nintendo/AMD. Ca profiterait a tout le monde. Ouai, je suis un hippie
    Dernière modification par newbie06 ; 06/02/2009 à 08h14.

  15. #285
    Si ma mémoire est bonne, à la base Sony comptait utiliser le Cell pour tout et se passer de GPU dans la PS3. Larrabee étant un ensemble de cores à l'origine généralistes, ça pourrait leur permettre de faire ça.

    Je ne sais pas si les performances single-thread seraient handicapantes, mais au pire ça pourrait être 2~4 cores de type Nehalem (enfin Sandy Bridge ou autre d'ici-là) avec plein de cores Larrabee autour.

    IBM a réussi à placer un CPU dans chaque console de la génération courante, je me demande s'ils peuvent réitérer l'exploit...

  16. #286
    PPC vient de sortir un dossier "Larrabee : le nouveau GPU d'Intel" :
    http://www.presence-pc.com/tests/int...tecture-22867/

  17. #287
    Merci pour le lien, parce que ça fait du bien de rire un peu de temps en temps.

  18. #288
    Mouai, ben y'a de sacrees erreurs sur le CELL.

    Un exemple :
    Le choix d’Intel simplifie grandement la programmation et permet d’éviter d’inclure un cœur plus généraliste comme le PPE. Ce système hétérogène est un des handicaps du Cell vu qu’il complique la vie du programmeur qui outre la gestion explicite de la mémoire doit également concevoir deux exécutables utilisant deux jeux d’instructions différents et donc deux compilateurs distincts.
    Sans deconner, le mec il a oublie que le PC a un processeur principal et que celui-ci n'est pas compatible avec les cores de Larrabee ?

    Ca devient hallucinant le nombre de personnes qui pensent que puisque c'est du x86, y'a rien a faire. x86 ca ne veut plus rien dire en terme de jeu d'instructions...

    Citation Envoyé par Møgluglu Voir le message
    Merci pour le lien, parce que ça fait du bien de rire un peu de temps en temps.
    Ouf, j'ai cru que c'etait mon cote primaire qui me faisait trouver l'article un peu limite
    Dernière modification par newbie06 ; 09/03/2009 à 13h28. Motif: Fusion automatique

  19. #289
    Je rappelle juste Fedy != Fefe
    fefe - Dillon Y'Bon

  20. #290
    Citation Envoyé par fefe Voir le message
    Je rappelle juste Fedy != Fefe
    Tu veux pas assumer tes erreurs, avoue

  21. #291
    C'est marrant j'ai pense exactement la meme chose.

    Alors fefe, ca va pas ? Des soucis ? T'en fais pas on a tous nos moments de faiblesse, y'en a meme qui n'ont que des moments de faiblesse.

  22. #292
    Citation Envoyé par newbie06 Voir le message
    Mouai, ben y'a de sacrees erreurs sur le CELL.
    Sur les GPU c'est pas mal non plus.

    Les GPU en s’appropriant les tâches les plus coûteuses en calculs rendaient complètement superflu les processeurs haut de gamme de la firme.
    Il pourrait au moins citer sa source : marketing NVidia.

    les applications les plus exigeantes en termes de puissance de calcul ont en général un flux d’instructions très linéaire : il y a peu de branchements et peu de dépendances entres les instructions
    Oui, c'est pour ça que les GPU ont des coeurs superscalaires très larges pour exploiter le parallélisme d'instruction... ah bah non.

    Une autre particularité intéressante de cette unité est sa capacité à effectuer des opérations de scatter/gather qui sont typiquement problématiques sur un GPU.
    Manque de bol, les GPU doivent être les seules archi modernes à gérer efficacement le gather voire le scatter, contrairement à Larrabee pour lequel ça risque d'être un problème majeur (ils dépendent beaucoup des caches pour diminuer les latences, et sur un gather la probabilité de cache miss explose).
    Dernière modification par Møgluglu ; 09/03/2009 à 14h10.

  23. #293
    Un petit article qui donne un avant-gout des extensions ISA : http://software.intel.com/en-us/arti...mitives-guide/

  24. #294
    Merci.

    Les instructions GATHERPFD et SCATTERPFD me rassurent sur la santé mentale des développeur d'Intel et permettent d'expliquer comment ils peuvent espérer faire du SIMD "sérieux" avec une archi in-order.

    Quelqu'un a la moindre idée de à quoi peut servir BITINTERLEAVE21_PI?
    Pour un split en 23/9 j'aurai compris, mais 21/11? Fonction câblée pour le raster? Ou juste bidouille pour gagner de la place?

    Des "float11", "float10" packés en 11:11:10 dans un 32-bits. Cool, ça fait presque 6 mois que le float16 est normalisé, il était temps d'inventer des nouveaux formats .

  25. #295
    Abrash, A First Look at the Larrabee New Instructions
    http://www.ddj.com/hpc-high-performa...ting/216402188

    Autres liens en vrac:
    Rasterization on Larrabee: A First Look at the Larrabee New Instructions (LRBni) in Action

    http://software.intel.com/file/15542

    SIMD Programming on Larrabee: A Second Look at the Larrabee New Instructions (LRBni) in Action

    http://software.intel.com/file/15545

    Beyond3D forum discussion of LRBni. Includes some tid-bits like how LRB handles exceptions when storing a vector. (It's pretty clever: the store instruction destructively modifies the write mask to all zeros. When the page fault happens the write mask is only partially cleared, and when the instruction is restarted only the vectors that haven't been written to yet will be written to:

    http://forum.beyond3d.com/showthread.php?t=53542
    PS - Tout ceci provient de RWT.

  26. #296
    [troll]
    J'ai beaucoup de respect envers Abrash, mais là je vois vraiment pas ce qu'il y a de révolutionnaire dans un jeu d'instruction SIMD qui reprend quelques instructions MMX et Altivec et complète avec des trucs qui existent depuis 5 ans sur n'importe quel GPU...
    [/troll]

  27. #297
    Tu te trompes, ca ressemble plutot a un bon vieux Cray (gather/Scatter Inside) d'il y a 30 ans plus qu'a un GPU d'il y a 5 ans.
    fefe - Dillon Y'Bon

  28. #298
    Exact.
    Vu que le GPU d'il y a 5 ans était déjà quasiment un Cray d'il y a 30 ans...
    (Le gather s'appelle pas comme ça, mais il y est.)

    Mais la vraie originalité de Larrabee est de combiner tout ça dans un jeu d'instructions d'il y a 25 ans et de l'implémenter sur une micro-archi d'il y a 15 ans.

  29. #299
    Le x86 a 30 ans aussi , et le P55C en a 20 tu es optimiste mais le concept y est !

    La difference est que ce n'est pas en AsGa mais dans un process CMOs recent !
    fefe - Dillon Y'Bon

  30. #300
    Il parlait pas d'instruction set mais de micro-archi. Et encore 15 ans il est généreux, comme toi tu l'es avec les 30 ans de l'ISA.

    C'était ma contribution mauvaise foi

Page 10 sur 19 PremièrePremière ... 23456789101112131415161718 ... 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
  •