Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 11 sur 19 PremièrePremière ... 345678910111213141516171819 DernièreDernière
Affichage des résultats 301 à 330 sur 567

Discussion: Intel et Larrabee

  1. #301
    En français, dossier sur Larrabee par Fedy Abi-Chahla.
    Article de Dandu présentant le dossier : http://www.presence-pc.com/actualite...uctions-34349/

    edit: exact fefe, je croyais avoir linké le dossier et non l'article
    Dernière modification par Foudge ; 09/04/2009 à 13h24.

  2. #302
    L'article que tu link est de Dandu . Meme si la suite est de Fedy
    fefe - Dillon Y'Bon

  3. #303
    Je suis fan.
    Surtout pour la partie sur les basculements de contexte en hard plus coûteux qu'en soft.

    Décidément, fefe a encore craqué.

  4. #304
    Citation Envoyé par fefe Voir le message
    L'article que tu link est de Dandu . Meme si la suite est de moi
    fixed
    Mes propos n'engagent personne, même pas moi.

  5. #305
    Fedy = Fefe, j'y crois pas une seconde

  6. #306
    Citation Envoyé par newbie06 Voir le message
    Fedy = Fefe, j'y crois pas une seconde
    On est pas à un hoax pres.
    Mes propos n'engagent personne, même pas moi.

  7. #307
    Ahah . Je vais me Alain Deloniser et donc parler de myself a la 3 eme personne.

    A propos des changements de contextes, il ne s'exprime pas tres bien mais tu as 4 possibilites:
    1. changer de contexte hard et pour ce devoir sauver l'etat d'un thread (ses registres) et restaurer celui du nouveau
    2. "changer" de contexte entre plusieurs threads SMT, leur etat n'a pas besoin d'etre restaure vu qu'il y a du hard dedie pour contenir l'etat de chaque thread.
    3. changer de contexte soft ou tu geres a la main la sauvegarde de ton etat au lieu de confier la sauvegarde/restauration au hard.
    4. "changer" de contexte soft entre plusieurs boucles d'un meme contexte hardware (ie Larrabee fibers).

    Le plus long est le 3 suivi du 1, buis viennent 2 et 4 (pas d'ordre entre 2 et 4). En effet 2 et 4 ne prennent pas de temps, la seule difference est que dans un cas la "concurrence" entre tes contextes est geree par le hard (thread scheduler) et l'autre par le programmeur qui a ordonnance ses boucles.

    Donc suivant ce que tu choisis de comparer tu peux arriver a la conclusion que de changer de contexte soft est moins couteux que de changer de contexte hard. Le seul probleme est que seuls 1 et 3 sont vraiment des changements de contextes. Le changement hard est probablement plus rapide en moyenne, mais un bon programmeur peut faire des optimisations quand il sait quelles parties de son etat il peut jeter, alors que pour le hard c'est plus dur a deviner.

    Dans 2 et 4 il n'y a pas reellement de changements de contexte.
    fefe - Dillon Y'Bon

  8. #308
    Sinon on voit assez bien sur la photo de HFR que le die de LRB est effectivement dans les 3x2cm
    fefe - Dillon Y'Bon

  9. #309
    Larrabee à l'IDF (voir en bas de page)

    http://www.hardware.fr/articles/757-...009-pekin.html

    Les prémonitions de fefe sur la taille du die semblent correctes...
    Edit : grilled
    http://valid.x86-secret.com/cache/banner/313021.png

  10. #310
    Citation Envoyé par fefe Voir le message
    En effet 2 et 4 ne prennent pas de temps, la seule difference est que dans un cas la "concurrence" entre tes contextes est geree par le hard (thread scheduler) et l'autre par le programmeur qui a ordonnance ses boucles.
    Donc les fibers de Larrabee sont juste des étages de pipeline logiciel? Je n'avais pas compris ça, à partir des présentations d'Intel j'imaginais des vrais threads légers.

    Du coup si j'ai un code genre:
    Code:
    for // i
    {
      if(cond(i)) {
        x = a[f(i)];
      }
      else {
        x = b[g(i)];
      }
    }
    le compilo va dupliquer la condition pour le compiler en:

    Code:
    for i % 512
    {
      mask1 = cond(i .. i+15); // Condition vectorielle
      if(mask1) {
        index1 = f(i .. i+15)
        GATHERPFD(a, index1, mask1)
      }
      else if(~mask1) {
        index1 = g(i .. i+15)
        GATHERPFD(b, index1, mask1)
      }
    
      mask2 = cond(i + 16 .. i + 31);
      if(mask2) {
        index2 = f(i + 16 .. i + 31)
        GATHERPFD(a, index2, mask2)
      }
      else if(~mask2) {
        index2 = g((i + 16 .. i + 31)
        GATHERPFD(b, index2, mask2)
      }
      // etc.
    
      if(mask1) {
        x1 = GATHERD(a, index1, mask1)
      }
      else if(~mask1) {
        x1 = GATHERD(b, index1, mask1)
      }
    
      if(mask2) {
        x2 = GATHERD(a, index2, mask2)
      }
      else if(~mask2) {
        x2 = GATHERD(b, index2, mask2)
      }
      // etc.
    }
    Dans ce cas simple on peut se démerder pour garder les fibers indépendants, mais avec du contrôle plus complexe (genre une boucle while avec un nombre variable de tours) ça ne marche plus et on se retrouve obligé de synchroniser les fibers? (attendre que tout le monde ait fini la boucle pour passer à la suite).

    Et à ce rythme-là, on va quand-même vite arriver au bout des 32 registres vectoriels et 8 masques, donc spiller dans le cache, ce qui revient indirectement à payer le coût des changements de contexte...
    Ils auraient au moins pu nous ressortir les registres glissants de l'Itanium, quand-même...
    Dernière modification par Møgluglu ; 09/04/2009 à 19h29.

  11. #311
    Citation Envoyé par Møgluglu Voir le message
    à partir des présentations d'Intel j'imaginais des vrais threads légers.
    Euh, si, je persiste et je relance sur le 3:

  12. #312
    Oui plusieurs boucles ou tu stockes dans le cache ce que tu ne veux pas garder dans tes registres quand tu passes a la suivante (saute a l'IP de ta boucle suivante) et recupere tes textures quand les autres ont fini leur execution.

    http://en.wikipedia.org/wiki/Coroutine

    Apres faut voir ce que tu entendais par thread legers.
    fefe - Dillon Y'Bon

  13. #313
    OK.
    Dans ce cas je ne vois pas la différence entre 3 et 4.
    Pour moi c'est un changement de contexte dans les deux cas : on sauvegarde les registres en vie, on transfère le contrôle et on restaure les registres, dans un ordre ou un autre.
    La seule différence que je vois est que dans 3 on sait exactement quels sont les registres qui ont besoin d'être sauvés. Mais sachant qu'il y en a un minimum qu'il faudra toujours sauver (eip, esp...), comment 4 pourrait être aussi voire plus rapide que 2?

    Edit: on peut overlapper la sauvegarde/restauration des registres avec des instructions indépendantes si on a un superscalaire assez large, c'est donc pour ça que le Vector Store peut être schedulé aussi dans l'unité scalaire et que toutes les instructions peuvent prendre un opérande en mémoire?...
    Dernière modification par Møgluglu ; 09/04/2009 à 20h59.

  14. #314
    Tu peux faire les Store en parallele avec les autres unites vectorielles donc si tu as bien schedule ta sauvegarde de registre elle te coute rien. Tes re-load ne te coutent rien non plus car les instructions font load-vector en 1 instruction, donc tant que tu as suffisament de travail a faire tu recouvres ta latence load+vector (qui est de toutes facons courte face au pipeline d'exec d'un WARP par ex.
    Sauver EIP/ESP n'est pas la ou est le cout, c'est sauver 32x512bits qui te coute quand tu fais des changements hard.
    fefe - Dillon Y'Bon

  15. #315
    Email d'Intel concernant Larrabee :

    Download the New C++ Larrabee Prototype Library :
    http://softwaredispatch.intel.com/?l...0BlsgSE4=&ch=e

    A First Look at the Larrabee New Instructions (LRBni) by Mike Abrash
    http://softwaredispatch.intel.com/?l...0BlsgSE4=&ch=e

    Peek into the Intel® Architecture Code-Named Larrabee with Tom Forsyth
    http://softwaredispatch.intel.com/?l...0BlsgSE4=&ch=e

    Read About Game Physics Performance on the Larrabee Architecture
    http://softwaredispatch.intel.com/?l...0BlsgSE4=&ch=e

  16. #316
    Je vois que certains recoivent la meme newsletter que moi

  17. #317
    Citation Envoyé par newbie06 Voir le message
    Je vois que certains recoivent la meme newsletter que moi
    On doit être même plusieurs milliers
    Même pas sûr qu'on soit mis au courant avant les autres, doit bien y avoir 1 PDF ou 2 qui ne datent pas d'hier

    faux edit: mwarf, même les librairies C++ datent du 1er avril. C'est du périmé comme info...

  18. #318
    Pour ceusse qui l'aurait loupé (comme moi il y a encore 5 minutes) : http://forum.canardpc.com/showthread.php?t=35623

  19. #319
    Encore une photo un poil + détaillée du die :
    http://www.pcinpact.com/actu/news/50...r-larrabee.htm
    http://valid.x86-secret.com/cache/banner/313021.png

  20. #320
    Bon bah au moins ça confirme les 32 cores observés par Sam. Par contre j'ai du mal à identifier le gros cache partagé...

  21. #321
    Cette photo est merdique. Autant prendre la version Photoshop : http://forum.beyond3d.com/showpost.p...1&postcount=14

  22. #322
    On voit assez bien 32 cores, 4 controleurs memoire au bord du chip avec les IO DDR ou GDDR en haut et en bas, les IO PCIE et probablement display a droite, et 8 unites contenant probablement les fonctions 3D trop lentes a faire en soft (comme le texture sampling).

    Le cache partage est tres certainement distribue entre tous les core, une seule banque de cache partagee aurait ete impossible a design avec assez de bande passante pour 32 cores. Par contre l'archi du reseau d'interconnection doit etre rigolotte avec 3 lignes de cores .
    fefe - Dillon Y'Bon

  23. #323
    Citation Envoyé par fefe Voir le message
    On voit assez bien 32 cores, 4 controleurs memoire au bord du chip avec les IO DDR ou GDDR en haut et en bas, les IO PCIE et probablement display a droite, et 8 unites contenant probablement les fonctions 3D trop lentes a faire en soft (comme le texture sampling).

    Le cache partage est tres certainement distribue entre tous les core, une seule banque de cache partagee aurait ete impossible a design avec assez de bande passante pour 32 cores. Par contre l'archi du reseau d'interconnection doit etre rigolotte avec 3 lignes de cores .
    C'est ce que je me suis dit pour le cache, mais du coup j'ai pas l'impression qu'il y ait 8 Mo de L2 + 8 Mo de L3 comme Sam l'indiquait dans sa news.

  24. #324
    Sam dit
    Hacun de ces cœurs est capable de traiter 4 threads en hardware, a été modifié pour supporter le jeu d’instructions 64-bit EM64T et dispose de 32 Ko de cache L1 ainsi que de 256 Ko de cache L2, ponctionné sur un gros cache L2 global.
    Et
    Embarque 32 cœurs (je les ai comptés sur le wafer de Gelsinger…), 8 Mo de cache L2 (32 x 256 Ko) et est cadencé à une fréquence comprise entre 1.5 et 2 GHz (je l’ai lu dans les entrailles d’une loutre).
    Donc il parle juste de 8Mo de L2 partage mais reparti entre les cores. Il ne parle pas de 8Mo de L3. Ca me semble concorder.
    fefe - Dillon Y'Bon

  25. #325
    OK j'ai dû rêver ! Faîtes comme si j'avais rien dit :D

  26. #326
    Qui plus est 8Mo de L2 distribue entre cores et 8Mo de L3 n'a aucun sens a moins d'avoir des caches exclusifs.
    Hors Intel fait des caches inclusifs en general et AMD des caches exclusifs.
    Qui plus est les caches exclusifs ont des problemes a scaler au dela de 2 cores (CF toutes les histoires originales de bande passante d acces TLB avec les premiers phenoms) ce qui est prouve aussi par l'ajout annonce par AMD de snoop filter. Dans un cache inclusif tu sais facilement quel cache contient quoi quand tu es le L3, dans une hierarchie exclusive tu passes ton temps a snooper. Ca va quand tu as 2 ou 4 cores mais 32 c'est l enfer. Il te faudrait un gros bloc de hardware pour filtrer les snoops (qui ferait la taille des tags d'un cache de 16 a 32Mo en gros, donc 20 a 40% de la taille d'un cache de 8Mo). Vu toutes les difficultes et l'historique des compagnies Intel ferait tres certainement un cache inclusif, et dans ce cas tu es bien force d'avoir un L3 qui contienne plus que la somme des L2 si tu veux que ca serve a quelque chose. Donc 8Mo de L3 avec 8Mo de L2 sur des chips Intel = tres tres improbable de toutes facons.
    fefe - Dillon Y'Bon

  27. #327
    Oui effectivement. Pourtant j'étais sûr d'avoir lu ça... Je dois devenir sénile avant l'âge.

    Du coup, ça veut dire qu'AMD va devoir passer à un cache inclusif en arrivant à 8 cores et plus ?

  28. #328
    Ou alors un gros snoop filter, qui est a priori plus la voie qu'ils ont choisi. Le probleme est que quand tu commences a mettre trop de cores tu as des problemes de bande passante vers ton snoop filter. A 8 cores ca doit encore etre faisable sans trop de difficultes, au dela, plus dur a mon avis.
    fefe - Dillon Y'Bon

  29. #329
    http://www.tomshardware.com/news/int...orce,7944.html

    Je ne suis pas trop d'accord : si Larrabee est actuellement déjà aussi rapide qu'une GTX285, je trouve ça plutôt bien, en tout cas mieux que ce à quoi je m'attendais.

  30. #330
    J'ai pas encore lu l'article, mais s'il est aussi rapide pour des applications similaires, oui c'est plutôt vachement bien je trouve, vu que si j'ai bien compris, une telle archi exprimerait son plein potentiel avec de nouveaux jeux d'instructions/nouvelles manières de coder
    pouet!

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
  •