Ha ouai, c'était plus grosso que modo alors
Ha ouai, c'était plus grosso que modo alors
Si vous permettez, je reviens avec mes latences mémoires et vos résultats.
Verticalement, la latence mémoire en ns pour des accès stream avec stride de 4K.
Les papillons sont des GTX 280 imaginaires qu'on aurait fait tourner aux même fréquences que les autres GPU, et les triangles vers la gauche sont des G80 imaginaires.
La première conclusion est : qu'est-ce que c'est moche les graphes sous OpenOffice... euh non, que si on regarde que les GPU "réels", la latence est relativement stable avec le temps à gamme équivalente (dans les 330ns).
Par contre, on voit aussi que le GT200 a une latence ~15% supérieure au G80 à fréquences équivalentes. Donc il y a bien une augmentation de la profondeur du pipeline mémoire, mais elle est compensée par une hausse de fréquence.
Dernière modification par Møgluglu ; 01/11/2009 à 23h47.
Marrant, pour l'axe vertical je voyais bien de quoi il s'agissait. L'axe horizontal c'est la date de release des drivers ?
Gnuplot ou Excel... Le reste c'est vraiment horrible.
La 8500GT est "bizarre"... Elle tournait a des frequences core vraiment basses ?
fefe - Dillon Y'Bon
Ca donne quoi sur des IGP, genre le 9400M ? J'en ai un, mais je peux pas tester, le Mac prppose pas la 9400M sous Windows.
Je continue dans ma démarche scientifique typique :
1. j'émets une hypothèse,
2. j'établis un protocole expérimental pour la vérifier,
3. je fais faire les tests par d'autres,
4. je triture les résultats dans tous les sens en considérant plein de métriques différentes sur le sous-ensemble de résultats qui m'arrange,
5. je trouve une façon de présenter les résultats qui confirme l'hypothèse de départ et conclue que j'avais raison.
:vieuxthésardaigri:
Donc, on en est à l'étape 4. Regarder juste les latences en isolation ne suffit pas à montrer que j'ai raison. Je dois donc essayer d'autres trucs. Par exemple calculer le produit latence * débit pour chaque GPU.
Latence * débit, ça fait multiplier des ns par des Go/s, ça fait des octets. Ça représente la quantité de données qui se baladent dans le pipeline mémoire à un instant donné.
Ce nombre est directement proportionnel au nombre de loads et de stores en vol. Pour être en vol en même temps il faut qu'ils soient exécutables en parallèles.
Sur un GPU, on exploite du parallélisme de données, avec plein de threads indépendants. Le nombre de threads doit donc être proportionnel au nombre de load/store.
Chaque thread a un contexte associé, contenant ses données temporaires. Sur un GPU, ce contexte est stocké dans les registres.
Le nombre de load/store en vol doit donc moralement être proportionnel au nombre de registres.
Donc je m'intéresse au facteur entre la taille des bancs de registres et celle des buffers mémoire.
Désolé, j'ai pas Excel et j'ai la flemme de faire ça bien avec gnuplot.
Horizontalement, c'est toujours les dates de sortie des GPU.
J'ai aussi mis l'intensité arithmétique (GFlops / débit mémoire), qui augmente régulièrement, c'est pas un scoop.
Les mauvaises langues diront qu'il n'y a que 2 points sur mon dessin, le G80 en bas à gauche et le GT200 en haut à droite et que tout le monde sait que le GT200 a 2 fois plus de registres.
Je prétends que si j'avais plus de points pour le G92, ils se situeraient grosso-Neo entre les deux autres GPU.
Bon, reste plus qu'à trouver un argument de mauvaise foi pour l'étape 5.
Dernière modification par Møgluglu ; 01/11/2009 à 23h47. Motif: Ajout 8800 GT
Besoin d'un G92 pour des tests ? J'ai une 8800GT sous WinXP.
Bah le café avec du sucre, ça fait des dommages collatéraux.
La metrique Flops/byes est sur une courbe de croissance lineaire depuis le debut des GPUs (j'ai trace les courbes ATI et vidia sur 10+ annees et la tendance est lineaire), en revanche chaque categorie de GPU est sur une courbe differente (en gros 3 courbes: integre, milieu de gamme et haut de gamme). Le nombre de flops / byte ne cesse d'augmenter. Pour le justifier il y a plusieurs types d'argumentation, a vous de choisir celle que vous preferez:
-les problemes que l'on traite sont de plus en plus complexes mais on n'a pas beaucoup plus de donnees en entree donc on a besoin de faire plus de calculs que d'acces memoire. Les GPUs s'adaptent aux nouveaux problemes en suivant cette tendance.
-la quantite d'unites de calcul sur un GPU augmente lineairement avec la surface alors que la quantite d'IOs augmente lineairement avec la peripherie (l'unite de mesure est la taille d'1 transistor). Donc forcement les flops augmentent plus vite que les bytes de bande passante. Les fabricants de hardware se debrouillent pour influencer suffisament le software de maniere a avoir des applis qui suivent la tendance.
-les 2: applications plus complexes et developpeurs qui s'adaptent au HW existant.
Quant a la capacite de stockage interne, elle devrait evoluer a la meme vitesse que min(dflops/dt, dbytes/dt) sauf qu'il faut en ajouter encore un peu plus pour conserver un IPC eleve en augmentant le nombre de threads (plus de buffers pour maintenir le scaling).
Je ne sais pas si ca va avec ta chaine de raisonnement .
fefe - Dillon Y'Bon
Je t'ai pas oubliay, mais... En fait si, j'ai booté mon pc chez mes vieux hier, et puis j'ai étay interrompu et hop, oubliay.
Mais je tache de faire ça le week end prochain...
Sinon, sur un netbook, t'as déjà benché ?
---------- Post ajouté à 09h57 ----------
Ben voilà. L'esperanto, çay le futur du passay.
Mes propos n'engagent personne, même pas moi.
À peu prés. Mes courbes de tendance bidon "montrent" que le nombre de registres augmente plus vite que le nombre de flops (à occupation du débit mémoire équivalente).
Mon interprétation est qu'on déplace les données plus près des core (de la DRAM vers les registres et/ou les caches de Fermi et Larrabee).
Pardon, je m'a gouré. J'avais compté 128SP au lieu de 112.
Avec 112 SP c'est nettement plus équilibré, comme quoi les SKU ne sont pas décidés totalement au pif en fonction du prix de la mémoire et des yields...
Merci! Pour Ion/9400M je suis curieux aussi de ce que ça donnerait.
Ben voilà. L'esperanto, çay le futur du passay.
En fait c'est juste que quand j'ai installé mon OS, il m'a posé une question du genre "Dans quelle langue habite ton clavier?" que j'ai trouvé tellement stupide que j'ai répondu un truc du genre "eo_DTC.GB-18030@brouzouf/pizza". Comme les locales ça marche pas de toute façon j'ai un OS en US English comme tout le monde, mais de temps en temps il y a un programme ou un site web qui me parle en Esperanto.
[/ma vie]
Merci Dandu, elle est marrante ta 9400M.
Si on regarde les résultats en détail (cette fois j'ai sorti gnuplot+imagemagick) :
Han, Foudge, met tes drivers à jour! Y'a plus que toi qui utilise des pages de 4K, tous les autres sont passés à 64K.
(Oui, chez NVidia ils s'amusent à changer régulièrement la taille des pages dans les drivers, allez vous amuser à benchmarquer après...)
La 9400M a un aliasing à 2K, et un truc qui ressemble à du prefetching (mais qui s'arrête à 4 Mo).
Mais surtout, il a pas de L2 de texture!
Ils ont moins d'1 an mes driver
Et c'est grave d'être à 4K (j'ai jamais fait gaffe) ?
Demain soir je passe aux 191.07/CUDA2.3, je relancerai le bench en fréquence par défaut + aux fréquences que tu m'as demander.
Non, non, te fatigue pas pour les drivers, et puis je trouve que c'est plus joli avec les 2 plateaux, ça met un peu d'originalité dans ces courbes toutes plates.
(et ça change pas les latences, ça décale juste les situations où il y a défaut de TLB )
Je remarquais juste que sur GPU même le résultat de benchs ultra-synthétiques comme ça peut changer complètement suivant l'évolution des drivers, c'est marrant (ou pas, suivant le point de vue...)
J'adore nVidia et son OptiX:
Dans le genre foutage de gueule...System Requirements
GPU*: NVIDIA Quadro FX or NVIDIA Tesla (GT200 class required for multi-GPU scaling and technical support)
*NVIDIA GeForce to be supported with NVIDIA's upcoming "Fermi" GPU architecture.
C'est pas supporté, mais est-ce que ça marche en pratique?
Apparemment je suis pas le seul à me poser des questions sur les latences mémoires, les threads et les registres :
http://pc.watch.impress.co.jp/docs/c...05_326442.html
Envoyé par Hiroshige Goto
Il arrive à peu près à la même conclusion que moi : sur Fermi on peut penser que le nombre de threads en vol ne suffit plus à masquer la latence mémoire en soit. Il faudra certainement exploiter les mémoires locales (explicitement ou implicitement) pour arriver à saturer la bande passante.
Ça suppose que la latence mémoire ne se réduit pas, hypothèse apparemment raisonnable, mais en même temps avec 350ns sur Tesla ils ont de la marge...
Un bel euphémisme à la japonaise à propos de Fermi et sa puissance de calcul non-utilisée :
Envoyé par Hiroshige Goto
De toute facon, nVidia a clarifie la situation : http://www.realtimerendering.com/blo...clarification/
Donc tout va bien
Je viens de tomber sur ce transparent montrant le bidule ExaScale de nVidia :
http://en.expreview.com/2009/10/29/n...e-in-2017.html
La partie qui m'interesse est celle-ci :
Je me demande bien quel type de CPU pourrait etre mis la-dedans, et a quoi ils serviraient exactement.2017 GPU Node: 2,400 throughput cores (7,200 FPUs), 16 CPUs
La ca nous fait 150 TP cores (450 FPUs) / CPU. J'imagine que le CPU ne peut alimenter directement tout ca en instructions ; donc ils seraient utilises a plus haut niveau pour dispatcher des taches.
Des avis ?
http://www.pcworld.fr/2009/11/16/mat...i-sc09/458981/
NVIDIA annonce sur son site internet qu'il fera une démonstration en direct de son architecture Fermi cette semaine.
Une conférence sur le supercomputing, pas sur qu'on voit un jeu tourner durant cette démo...
Amusant d'ailleurs, l'inauguration aura lieu sur les terres d'Intel (Portland Oregon).
En exclusivité sur CanardPC, mes premières impressions sur le jeu d'instruction de Fermi, après une euh... petite analyse des binaires produits par CUDA 3.0 beta :
- Pour le RISC, Patterson il repassera... C'est vrai que le codage des instructions est un peu plus régulier que dans Tesla, et surtout il y a moins de modes d'adressage exotiques. Mais pas de révolution par rapport à Tesla.
En fait, il y a 8 grandes catégories d'instructions (SP, DP, int, mem, contrôle...) entre lesquelles le codage est assez différent, mais il n'y a en général pas besoin de lire l'opcode pour décoder les opérandes.- Le load-store unifié, c'est du bullshit. On a toujours les instructions flottantes qui peuvent prendre des opérandes en mémoire de constantes, et c'est très bien comme ça. (Par contre en entier c'est pas possible.)
- La prédication et le contrôle : il y avait une phrase obscure dans le whitepaper de NVidia à laquelle personne n'avait rien compris. Maintenant, je peux dire que... j'ai toujours pas compris.
Mais ils ont effectivement simplifié (au niveau archi) et probablement compliqué (au niveau microarchi) leur mécanisme de branchements.- En CUDA, les pointeurs GPU sont de la même taille que les pointeurs CPU. Fermi supporte indifféremment des pointeurs de 32 et 64 bits, c'est un bit dans les instructions load et store qui dit la taille de l'adresse.
Le hic, c'est qu'il n'y a plus de registre d'adresse dédiés et d'instructions de calcul d'adresse comme sur Tesla, et que les unités arithmétiques sont toujours 32-bit. Donc surcoût non négligeable en code, registres et temps sur x64...- Quelques nouvelles instructions comme les insert/extract de bitfields, les shift+add, les pack + broadcast pour échanger des booléens entre threads adjacents, des réductions de booléens (and, or, popcnt horizontal) sur tout un bloc CUDA...
Globalement à vue de nez, l'augmentation de la taille de code due aux pointeurs est plus ou moins compensée par l'utilisation des nouvelles instructions et l'amélioration de la souplesse d'utilisation des instructions existantes (plus de possibilités de caser des immédiats). Il était temps d'avoir une vraie multiplication 32x32 aussi.
Rien vu encore sur les exceptions et les call indirects qu'on nous avais promis, faudra attendre le compilo suivant.
Désolé pour le pavé.