Intel les rachetera pour utiliser la techno dans LRB 2.
Intel les rachetera pour utiliser la techno dans LRB 2.
Du NV40 à Fermi, avec tout plein de zolies jimages :
http://pc.watch.impress.co.jp/docs/c...23_323529.html
Si on compte les bubulles dans le pipeline, on voit que :
- Le taux d'utilisation max des unités (débit de dispatch des instructions / nombre d'unités) diminue.
- Le nombre de threads / unité diminue. On reboucle plus souvent sur les mêmes threads, donc soit le pipeline et la latence mémoire sont plus courts, soit il y a plus de mécanismes pour exploiter l'ILP (à commencer par le cache), soit le taux d'utilisation effectif diminue.
En continuant à spéculer sauvagement, le communiqué de Patterson indique le passage d'un jeu d'instruction complexe à un jeu d'instruction RISC load/store, ce qui pour moi veut dire qu'il faudra plus d'instructions pour faire le même boulot... Donc perfs plus faibles à IPC égal.
Donc IPC superieur sinon c'est foutu
Mais si on met plus d'unités et qu'on veut conserver le ratio calcul/mémoire, on a besoin de plus de ports à un niveau ou un autre de la hiérarchie mémoire...
ce qui fait augmenter la latence mémoire moyenne.
Et pour masquer cette latence mémoire, il faut avoir plus de threads en vol par core, sinon l'IPC est limité par la latence et c'est plus un GPU.
Et donc les many-core à mémoire partagée ça scale pas.
C'est un truc dont je suis persuadé et que j'essaie de montrer/quantifier depuis un moment. Mais c'est pas facile de trouver des chiffres.
Dans ma todo list, il y a : coder un microbenchmark de mesure de latence en OpenCL et faire un appel à volontaires chez les canards pour tester ça sur tous les GPU des 3 dernières années pour essayer de dégager une tendance...
Parce qu'une tendance avec 3 points c'est pas ça.
Si tu fais un truc qui tourne sous Linux, je pourrai le tester sur ma GTX275 (mais pas en OpenCL, sauf si t'attends que ça soit dispo en package pour F11, je suis une flemmasse ).
Et pour me remercier, tu m'expliqueras la blague de l'engineer.
J'ai un sacre packet de CG sur mon bureau donc si ton truc tourne sous windows et que je trouve le temps je peux essayer de contribuer a la science .
fefe - Dillon Y'Bon
nvcc suffit, donc ça devrait aller
Ouep, mais nvcc à encore quelques petits soucis de compatibilité avec les GPU AMD (et autres...), il parait.
Merci newbie et fefe pour votre contribution à la Science...
Chez NVidia il y a clairement eu une augmentation de la latence entre le G80 et le GT200. C'est assez flagrant dans la gamme Tesla (mais la mémoire est passée de 1.5 à 4 Go avec une fréquence moindre aussi). C'est partiellement compensé par la hausse des fréquences, mais en gros l'augmentation serait de l'ordre de 5-10% par génération (G80, G92, GT200).
(Sur CPU, la latence baisse de quelques % par an en moyenne, non?)
Dans le haut de gamme "consumer" avec GDDR3, ça reste entre 320 et 350 ns.
Par contre les cartes apacher avec DDR2 (8500 GT) ont une latence énorme (530ns).
Ça montre que l'archi est optimisée seulement pour le HDG, et qu'on se contente de copier-coller en baissant les fréquences pour faire le BDG...
Wanted : une GeForce 8800 GTX originale pour avoir un vrai point de référence. Si j'ai bon, la 8800 Ultra devrait détenir le record de latence, avec la GTX pas loin derrière.
La machine sur laquelle je compte tester a une 8800GTX premiere generation dessus en ce moment...
fefe - Dillon Y'Bon
La seule chose qui importe c'est le rapport calculs executes/memoire. Si tu ajoutes des unites et les utilises moins efficacement tu n'as pas besoin d'augmenter ta bande passante memoire. Bien entendu ca te rajoute de la bande passante sur ton reseau d'interconnexion.
En revanche pour ajouter des unites tu es oblige de descendre la frequence si ton budget power est limite: donc tu ajoutes on va dire 30% d'unites pour masquer une baisse de 20% d'IPC et tu descend la frequence et le voltage de 10% ce qui te gagne 30% de power. Baisser la frequence sans changer d'archi augmente ta latence si tu as beaucoup de cycles (en allant vers ta memoire) dans le domaine de frequence que tu viens de reduire.
Et oui tu as ajoute pas mal de cores donc tu finis par ajouter plus de threads et de stockage dans tes buffers (ou a mieux partager l'espace de buffer entre threads) pour pouvoir recouvrir la latence memoire. C'est la meme chose sur CPU (pour les applis server) d'ailleurs. Pour tes buffers vu qu'en general ils sont accoles aux unites de calcul' en augmentant de 30% tes unites de calcul tu as ajoute 30% d'espace de buffer, et tu ajoutes 30% de threads en plus. Et Voila .Et pour masquer cette latence mémoire, il faut avoir plus de threads en vol par core, sinon l'IPC est limité par la latence et c'est plus un GPU.
Et donc les many-core à mémoire partagée ça scale pas.
Bien entendu c'est horriblement simplifie parce que je parts du principe que tous les threads qui tournent sont homogenes et que ajouter de la bande passante sur le reseau d'interconnexion (le switch ou le ring ont plus d'agents) est simple...
fefe - Dillon Y'Bon
C'est un peu passé inaperçu, mais S3 annonce que sa nouvelle puce embarquée est compatible OpenCL.
Vu qu'elle est basée sur la même puce que les Chrome 400/500 on peut espérer que ces dernières deviennent compatibles.
Bon en même temps vu le nombre de personnes qui ont pu avoir une de leur carte entre les mains
Mais OpenCL c'est pas un langage pour le GPGPU gratos supporté par le groupe Kronos ?
Sinon j'ai eu une 440GTX entre les mains : les drivers ne sont pas aussi pourris que je le pensais
OpenCL est largement inspiré de Cuda si je me rappelle bien, Nvidia ayant été un des principaux contributeurs de ce standard. C'est d'ailleurs un des reproches qui lui a été fait. Bon faut dire qu'à l'époque ATI avec son CTM était pas au top. Il se rattrape maintenant avec DX11.
Ouep, en gros OpenCL est la standardisation a posteriori de CUDA, et le Compute Shader de DX11 est la standardisation de CAL d'AMD.
Comme ça au lieu d'avoir 2 API propriétaires on a 2 standards, ça change tout.
Il y avait 2 API proprietaires et 1 standard (j'ignore volontairement OpenGL), maintenant il y a 2 standards , ca va quand meme dans le bon sens...
fefe - Dillon Y'Bon
DirectX et standard côte à côte, vous me foutez la gerbe
C'est un standard de facto... D'ailleurs je ne serais pas supris qu'à terme, Direct Compute soit bien plus utilisé qu'OpenCL, un peu comme Direct3D et OpenGL.
Pour qu'un truc soit un standard, il faut un machin genre spec implémentables partout ?
Mes propos n'engagent personne, même pas moi.
Ouai, et c'est exactement pour ca que ca me fout la gerbe. Comme le x86 est le standard de facto, comme Windows est le standard de facto, comme ARM est le standard de facto en telephonie.
Je vais me reprendre un cafe
---------- Post ajouté à 10h27 ----------
Pour moi un standard, c'est au moins une masse critique de competiteurs qui se mettent d'accord.
Et encore, là c'est bien parce qu'il est une semaine à la bourre pour le changement d'heure, d'habitude je suis sûr qu'il se lève encore plus tard.
Ha, je vous surprends à tirer des conclusions sur une heure de levée sans rien pour l'étayer : on ne prend pas de café uniquement au lever.
Si le reste de vos commentaires est tout aussi infondé, je vais plus viendre ici moi.
Je suis passé au paracétamol, ça a moins de goût que le café, mais ça me soignera ptet au moins
Et pour pas faire 100% hors-sujet : http://www.pcinpact.com/actu/news/53...-fps-19539.htm
Oui j'arrive au boulot a l'heure a laquelle vous en partez grosso-modo .
fefe - Dillon Y'Bon
C'est cool par chez toi, ça veut dire que t'arrives à 10h