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

Discussion: Archi GPU et GPGPU

  1. #301
    Ha ouai, c'était plus grosso que modo alors

  2. #302
    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.

  3. #303
    Marrant, pour l'axe vertical je voyais bien de quoi il s'agissait. L'axe horizontal c'est la date de release des drivers ?

  4. #304
    Citation Envoyé par newbie06 Voir le message
    L'axe horizontal c'est la date de release des drivers ?
    De release des GPU d'aprés Wikipedia ou moi. La faute à OpenOffice si c'est pas marqué dans la légende.
    (le but original étant de dégager une tendance de l'évolution de l'archi dans le temps)

  5. #305
    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

  6. #306
    Citation Envoyé par fefe Voir le message
    La 8500GT est "bizarre"... Elle tournait a des frequences core vraiment basses ?
    459 MHz core, 918 MHz shaders, 400 MHz mémoire.

    C'est pour ça que je disais un peu plus haut que l'archi n'est pas du tout optimisée pour le bas de gamme... Pour nourrir un pauvre bus DDR2-800 sur 128-bit, c'est des latences délirantes.

  7. #307
    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.

  8. #308
    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

  9. #309
    Besoin d'un G92 pour des tests ? J'ai une 8800GT sous WinXP.

  10. #310
    Citation Envoyé par newbie06 Voir le message
    Ha ouai, c'était plus grosso que modo alors
    Tu serais pas en train de dire que je suis gros, quand même ?
    Mes propos n'engagent personne, même pas moi.

  11. #311
    Bah le café avec du sucre, ça fait des dommages collatéraux.

  12. #312
    Citation Envoyé par Foudge Voir le message
    Besoin d'un G92 pour des tests ? J'ai une 8800GT sous WinXP.
    Images mises à jour avec la 8800 GT, merci Foudge pour les tests.

    Elle se place quasiment sur la ligne de tendance, si c'est pas beau ça...
    (par contre question ratio flops/mémoire elle est largement déséquilibrée... )

  13. #313
    Citation Envoyé par dandu Voir le message
    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.
    Mauvaise excuse, CUDA ça tourne très bien sous MacOS X.
    Si tu es prêt à installer CUDA et compiler le bench, je suis intéressé...

  14. #314
    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

  15. #315
    Citation Envoyé par Møgluglu Voir le message
    Images mises à jour avec la 8800 GT, merci Foudge pour les tests.

    Elle se place quasiment sur la ligne de tendance, si c'est pas beau ça...
    (par contre question ratio flops/mémoire elle est largement déséquilibrée... )
    Déséquilibré dans quel sens ? Ca m'a pas l'air bien différent des autres 8800, si ?

  16. #316
    Citation Envoyé par Møgluglu Voir le message
    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.
    http://tof.canardpc.com/view/d00d025...95b6fdc7c0.jpg

    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.
    OK on s'en fout, mais pourquoi tes légendes sont en... euh, c'est quoi cette langue d'ailleurs ? Google m'envoie vers de l'Esperanto

  17. #317
    Citation Envoyé par Møgluglu Voir le message
    Mauvaise excuse, CUDA ça tourne très bien sous MacOS X.
    Si tu es prêt à installer CUDA et compiler le bench, je suis intéressé...
    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 ----------

    Citation Envoyé par Alexko Voir le message
    OK on s'en fout, mais pourquoi tes légendes sont en... euh, c'est quoi cette langue d'ailleurs ? Google m'envoie vers de l'Esperanto
    Ben voilà. L'esperanto, çay le futur du passay.
    Mes propos n'engagent personne, même pas moi.

  18. #318
    Citation Envoyé par Neo_13 Voir le message
    Sinon, sur un netbook, t'as déjà benché ?
    Faudrait que ce soit un netbook a base de nVidia ION, et y'en a pas des masses...
    C'est un 9400M ION ?

  19. #319
    Citation Envoyé par fefe Voir le message
    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 .
    À 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).

    Citation Envoyé par Foudge Voir le message
    Déséquilibré dans quel sens ? Ca m'a pas l'air bien différent des autres 8800, si ?
    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...

    Citation Envoyé par Neo_13 Voir le message
    Mais je tache de faire ça le week end prochain...
    Sinon, sur un netbook, t'as déjà benché ?
    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]

  20. #320
    Citation Envoyé par Møgluglu Voir le message
    Mauvaise excuse, CUDA ça tourne très bien sous MacOS X.
    Si tu es prêt à installer CUDA et compiler le bench, je suis intéressé...
    Ben oui, je veux bien tester, j'ai une 9400M (avec DDR3), une 9600 avec mémoire dédiée et je peux tester une 8600M avec peu de mémoire (si ça a un impact)

  21. #321
    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!

  22. #322
    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.

  23. #323
    Citation Envoyé par Foudge Voir le message
    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...)

  24. #324
    J'adore nVidia et son OptiX:

    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.
    Dans le genre foutage de gueule...

  25. #325
    Citation Envoyé par newbie06 Voir le message
    J'adore nVidia et son OptiX
    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

    Citation Envoyé par Hiroshige Goto
    GPUはレジスタモンスターだ。
    (Les GPU sont des Register Monsters.)


    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 :
    Citation Envoyé par Hiroshige Goto
    http://pc.watch.impress.co.jp/docs/c...02_325517.html
    ヘッドルームを持ったアーキテクチャだと言うことができる。
    (On peut dire que c'est une architecture qui a du Headroom.)

  26. #326
    Citation Envoyé par Møgluglu Voir le message
    C'est pas supporté, mais est-ce que ça marche en pratique?
    De toute facon, nVidia a clarifie la situation : http://www.realtimerendering.com/blo...clarification/
    Donc tout va bien

  27. #327
    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 :
    2017 GPU Node: 2,400 throughput cores (7,200 FPUs), 16 CPUs
    Je me demande bien quel type de CPU pourrait etre mis la-dedans, et a quoi ils serviraient exactement.

    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 ?

  28. #328
    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).

  29. #329
    Citation Envoyé par Yasko Voir le message
    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).
    C'est même assez peu probable. Espérons que cette fois, la carte présentée ne soit pas factice...

  30. #330
    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é.

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
  •