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
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 à 12h24.
L'article que tu link est de Dandu . Meme si la suite est de Fedy
fefe - Dillon Y'Bon
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é.
Fedy = Fefe, j'y crois pas une seconde
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
Sinon on voit assez bien sur la photo de HFR que le die de LRB est effectivement dans les 3x2cm
fefe - Dillon Y'Bon
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
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:
le compilo va dupliquer la condition pour le compiler en:Code:for // i { if(cond(i)) { x = a[f(i)]; } else { x = b[g(i)]; } }
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).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. }
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 à 18h29.
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
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 à 19h59.
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
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
Je vois que certains recoivent la meme newsletter que moi
Pour ceusse qui l'aurait loupé (comme moi il y a encore 5 minutes) : http://forum.canardpc.com/showthread.php?t=35623
Encore une photo un poil + détaillée du die :
http://www.pcinpact.com/actu/news/50...r-larrabee.htm
Bon bah au moins ça confirme les 32 cores observés par Sam. Par contre j'ai du mal à identifier le gros cache partagé...
Cette photo est merdique. Autant prendre la version Photoshop : http://forum.beyond3d.com/showpost.p...1&postcount=14
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
Sam dit
EtHacun 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.
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.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).
fefe - Dillon Y'Bon
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
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 ?
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
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.