Je ne suis pas convaincu que ce type de machines serve pour le grand public : au final peu de soft ont besoin de faire du flottant, en tout cas à ce niveau de perf. Et s'il y avait un tel besoin de perf flottantes, je pense qu'on aurait vu bien plus d'applications GPGPU grand public.Originally Posted by Sp1d3r
/agree.
Je ne suis certainement pas a la page, mais cote grand public en dehors du transcodage video (qui est plus efficace avec un accelerateur dedie inclu dans les 2 dernieres generation de CPU Intel entre autre et qui arrive chez AMD), il y a quoi comme Appli qui fasse du GPGPU. Les applis Adobe comme CS5/6, mais je n'ai pas vraiment vu la difference a l'utilisation (et puis Photoshop c'est pas vraiment grand public), quoi d'autre ?
fefe - Dillon Y'Bon
De temps en temps, AMD (entre autres) évoque la reconnaissance faciale ou vocale. Mais je ne suis pas entièrement convaincu que ça ait réellement un intérêt pour le grand public non plus.
Mon blog (absolument pas à jour) : Teχlog
Le jeu vidéo ?
Tu penses qu'Intel a définitivement abandonné l'idée d'essayer d'en faire un GPU (castré en DP pour ne pas concurrencer les Xeon Phi) ?
@Møgluglu:
Aucune idee. Je n'y connais pas grand-chose, mais j'ai quand meme l'impression que sans unites dediees a certaines taches faire un GPU performant est illusoire. J'irais meme un cran plus loin (a prendre avec des pincettes) : il est probable que le parallelisme doive etre bien plus massif pour faire un GPU efficace (les specialistes me corrigeront).
Moi je ne sais pas. Mais Intel ils ont déjà essayé... et ils ont eu des problèmes.
Pour le parallélisme, ça ne me choque pas plus que ça : 16 (voies SIMD) * 4 (threads SMT) * 8 (threads SoE "fibers") * 50 (cores), ça fait 25600 threads. C'est raisonnable par rapport aux 25000 pour le GF100, 31000 pour le GK110 et 82000 pour GCN. (Je n'ai pas vu de mention explicite du nombre de fibers employés en pratique, sinon que c'est assez pour couvrir la latence de l'unité de texture.)
S'ils arrivent à saturer leur unités de calcul avec moins de threads que les concurrents (grâce à plus d'ILP ou une latence mémoire moyenne plus faible), c'est autant de gagné en localité dans les caches et c'est tout bénef pour eux.
S'quoi le SoE ?
Switch on event. Le modèle d'exécution des shaders de Larrabee prévoyait des basculements de contexte en niveau user entre threads pour couvrir les latences de sampling de texture.
L'idée du scheduling à 2 niveaux n'est pas débile, AMD le fait depuis longtemps et on trouve même des papiers de Nvidia Research qui le réinventent.Le faire en soft a un coût supplémentaire, mais pas forcément délirant.
Ils peuvent donc avoir autant de parallélisme qu'ils veulent. Mais au final, c'est toujours la capacité du cache L1 ou du banc de registres GPU qui va dicter le nombre de threads. Et s'ils sont toujours à 32K de L1D/core, la comparaison n'est pas à l'avantage de Larrabee...
S'ils avaient mis autre chose que du x86 ils auraient gagne assez de place pour passer de 32k a 64k. Quoi, je trolle ?
S'ils avaient mis autre chose que du x86 ils n'auraient pas besoin d'autant de cache L1 parce qu'ils auraient un nombre décent de registres et des conventions d'appel potables.
Bah pour l'ABI c'est du x86_64, y'a pire hein.
Y'a un endroit ou on peut reclamer une carte gratos quand on n'est pas au CERN ?
De toute façon, il n'y a pas de registres dédiés à LRBni, de la même façon qu'il y a des registres SSE ?
Mon blog (absolument pas à jour) : Teχlog
Oui, tu as les registres vectoriels, 32 de 512-bit.
Rhôo, moi aussi je peux troller si je veux…
La différence, c'est que sur les GPU les données privées des threads sont allouées de manière statique dans un gros banc de registres partitionné entre les threads (#registres/thread variable) et ne bougent plus, tandis qu'avec Larrabee on passe par le cache L1 à chaque basculement de contexte.
A priori l'approche Larrabee est plus coûteuse, mais le nombre de registres / thread variable a un gros désavantage : la génération de code dépend du contexte. C'est un sacré problème pour la composabilité : on ne peut pas compiler séparément la moindre fonction de bibliothèque, parce que suivant l'endroit où elle est appelée, "l'architecture cible" sera différente. C'est une des raisons qui oblige à avoir du JIT de partout dans les drivers GPU.
En ce sens, le x86 (au sens de jeu d'instruction CPU classique, ça pourrait aussi bien être ARM ou PPC ou Alpha...) peut être vu comme un avantage.
Euh... Tu peux toujours demander.
On n'est pas concurrents sur le HPC. Enfin pas encore
Quelques détails sur Xeon Phi
http://www.hardware.fr/news/12577/qu...-xeon-phi.html
http://communities.intel.com/communi...t-hot-chips-24
Je ne suis toujours pas convaincu.
Je me posais une question sur Xeon Phi. Il n'y a pas de versions scalaires des instructions flottantes SIMD dans le jeu d'instructions comme en SSE/AVX.
Du coup, en quoi est compilé le flottant scalaire (par icc et dans l'idée d'Intel) ?
1) en instructions x87,
2) en instructions SIMD sur des vecteurs de 512 bits,
3) en instructions SIMD prédiquées par le masque 0000000000000001,
4) ça n'existe pas, icc sait tout vectoriser.
La réponse 3) me semble la plus raisonnable. La solution 1) pose des problème de déterminisme des résultats entre le même calcul vectorisé et non-vectorisé (bon, c'était déjà le cas avant), et l'ABI copié-collée sur celle du x86_64 relègue x87 aux calculs en double-étendue. La solution 2) doit poser des soucis avec les traps et les exceptions (ah non pardon, Phi gère pas les exceptions flottantes), en plus d'être pas super efficace en énergie. Pour 4), no comment.
La solution 3 voudrait dire :
- Le compilo doit initialiser un registre de masque à 00…01 dans chaque fonction qui manipule du flottant scalaire. Et le refaire entre chaque appel de fonction, les registres ki étant temporaires d'après l'ABI.
- On a plein d'écritures partielles, et la micro-archi voit des dépendances de partout. Pas trop gênant encore en in-order, mais en out-of-order bon courage…
- A-t-on une voie privilégiée ? Si je décide de choisir plutôt le masque 0000001000000000, je consommerait autant ? Ça voudrait dire que les datapaths et les registres sont clock-gatés et banqués à une granularité de 64 bits, voire 32 bits ?
Plus de résultats de bench Xeon Phi (mais toujours par Intel) : http://www.intel.co.jp/content/dam/w...ance-brief.pdf
50% du débit crête sur la mémoire, c'est pas terrible ?
Je n'ai pas trouvé de chiffres pour Kepler, mais sur Fermi c'était autour de 80% (ECC on).
Je trouve surtout etrange d'utiliser triad pour mesurer la BP surtout sur un processeur in order, non ?
Bah ils doivent software-prefetcher à fond de toute façon. Plus il y a de loads en vol, mieux c'est. Et le ratio lectures:écritures de 2:1 est probablement plus intéressant.
Sinon au temps pour moi, 80% c'est pour du trafic en lecture uniquement. Sur triad, on doit plutôt tomber à 70% à la louche.
Posting Permissions
Reply With Quote
