Crunchez vos adresses URL
|
Calculez la conso électrique de votre PC
|
Hébergez vos photos
Page 14 sur 22 PremièrePremière ... 4678910111213141516171819202122 DernièreDernière
Affichage des résultats 391 à 420 sur 658

Discussion: Archi GPU et GPGPU

  1. #391
    Non, c'est certainement par fuse.

    En même temps, le fait qu'à peu près aucune review n'ait mentionné ce "détail" tend plutôt à montrer que les gamers s'en foutent.
    Et puis la feature est toujours-là, c'est juste que la carte est "optimisée gaming" plutôt que "optimisée compute", tout comme les Quadro sont "optimisées OpenGL" et pas les GeForce... (en langage PR)
    Dernière modification par Møgluglu ; 02/04/2010 à 07h28. Motif: Autocensure

  2. #392
    He bien, ca rend la carte encore moins interessante que je ne la trouvais

  3. #393
    Genre on optimise pour le gaming en enlevant des features qui en theorie n'ont aucun impact sur l'existant et qui peuvent juste encourager des devs a coder autrement...
    Ca me semble bizarre de mettre les circuits sur toutes les cartes pour ne les activer que sur quelques %. c'est pas comme si leur die etait petit a la base.

    D'un poitn de vue financier ca n'a aucun sens a moins que ca soit si peu cher que le volume des cartes "pro" multiplie par leur prix ridicule soit suffisant pour amortir le cout en surface d'une feature fused off sur 99% des dies produits (corrigez moi si la part de marche des cartes "pro" est plus de 1/100 des cartes gamers, je parle des cartes vendues bien sur, pas de celles genereusement donnees a des instituts de recehrche )

    ---------- Post ajouté à 18h25 ----------

    Citation Envoyé par newbie06 Voir le message
    He bien, ca rend la carte encore moins interessante que je ne la trouvais
    Je n'ai toujours pas trouve de raisons d'upgrader ma 8800GTS512... Le jour ou j'achete un 30" peut-etre ?
    fefe - Dillon Y'Bon

  4. #394
    Citation Envoyé par fefe Voir le message
    Je n'ai toujours pas trouve de raisons d'upgrader ma 8800GTS512... Le jour ou j'achete un 30" peut-etre ?
    Ma GTX 275 va bien sur mon 24" aussi, aucune raison d'en changer, sauf si j'avais pu avoir un monstre en DP pour m'amuser. Le probleme est clairement regle maintenant

  5. #395
    Citation Envoyé par fefe Voir le message
    Genre on optimise pour le gaming en enlevant des features qui en theorie n'ont aucun impact sur l'existant et qui peuvent juste encourager des devs a coder autrement...
    Ca me semble bizarre de mettre les circuits sur toutes les cartes pour ne les activer que sur quelques %. c'est pas comme si leur die etait petit a la base.

    D'un poitn de vue financier ca n'a aucun sens a moins que ca soit si peu cher que le volume des cartes "pro" multiplie par leur prix ridicule soit suffisant pour amortir le cout en surface d'une feature fused off sur 99% des dies produits (corrigez moi si la part de marche des cartes "pro" est plus de 1/100 des cartes gamers, je parle des cartes vendues bien sur, pas de celles genereusement donnees a des instituts de recehrche )
    Je te rassure, les Tesla gratuites c'est fini, la crise, toussa...

    Mais dans des conditions "supply-constrained", ils ont tout intérêt à vendre le maximum de Tesla à haute valeur ajoutée, et seulement compléter avec des GeForce...
    Tout utilisateur forcé à upgrader en Tesla est bon à prendre.
    Et il n'y a pas grand-monde qui va acheter une Radeon à la place d'une GeForce juste pour ses perfs en double précision. Ce n'est pas comme s'ils avaient de la concurrence en GPGPU...

    Mais sinon oui, ça a probablement aussi un intérêt en yield*fréquence/conso...

    Je n'ai toujours pas trouve de raisons d'upgrader ma 8800GTS512... Le jour ou j'achete un 30" peut-etre ?
    Non, 3 moniteurs 120Hz pour faire de la 3DVision Surround, avec 2 GTX 480 bien sûr parce qu'on est pas foutus de mettre plus de 2 sorties vidéo par carte.

  6. #396
    Lapack sur Tesla C2050 (donc double précision non castrée) :
    http://www.culatools.com/blog/2010/0...mi-performance

    Il reste à attendre la version spécifiquement optimisée Fermi (basée sur les cuBLAS de CUDA 3.1)...

  7. #397
    En gros, c'est jusqu'à 3~4 fois mieux qu'un Core i7 920... Va falloir attendre la version optimisée pour Fermi, parce que là niveau perfs/$ c'est franchement pas bon. Aux dernières nouvelles c'est $2499 pour le C2050.

  8. #398
    C'est toujours nettement plus rentable que la génération précédente qui ne dépasse pas le Core i7.
    Et les $2499 sont tout à fait raisonnables face à une config genre quadri-socket Nehalem EX.

    Et pour le reste, il y a les GeForce... ah bah non pas en double précision.

  9. #399
    Citation Envoyé par Møgluglu Voir le message
    C'est toujours nettement plus rentable que la génération précédente qui ne dépasse pas le Core i7.
    C'est clair !

    Citation Envoyé par Møgluglu Voir le message
    Et les $2499 sont tout à fait raisonnables face à une config genre quadri-socket Nehalem EX.

    Et pour le reste, il y a les GeForce... ah bah non pas en double précision.
    Certes, si tu commences à considérer du multi-socket, ça devient plus cher pour les CPU, même s'il ne faut pas oublier que Tesla tout seul ne suffit pas, faut un CPU avec, donc c'est un coût additionnel.

    Face à du dual-Westmere ou dual-Magny-Cours, faut voir ce que ça donne.

  10. #400
    Ca peut devenir interressant si tu peux aligner plusieurs de ces cartes par machine, sinon un dual socket de 6 cores restera plus interressant financierement.

    Apres en GFLOP/Watt a la prise, je doute que le C2050 batte un CPU actuel, pour une farm de calcul ca rentrera en compte dans la rentabilite (ca sera certainement plus compact mais plus cher a refroidir et je ne sais pas comment faire ces calculs).

    Si on ignore completement la plateforme necessaire au support de ces calculs. Combien consomme le i7-920 qu'ils comparent contre le Tesla.
    fefe - Dillon Y'Bon

  11. #401
    Citation Envoyé par fefe Voir le message
    Si on ignore completement la plateforme necessaire au support de ces calculs. Combien consomme le i7-920 qu'ils comparent contre le Tesla.
    Le TDP est de 130W, mais il faudrait plutôt comparer Fermi à Gulftown sorti à peu près au même moment. Celui du C2050 est (officiellement ) 247W en comptant la mémoire.

    Donc en gros, on doit être dans les même eaux qu'un dual-socket de 6-core pour la conso, voire un peu en dessous...
    Pour la densité, il y a des tarés qui mettent 4 C2050 par rack 4U (système complet), ou 2 par 1U (accélérateur seul)...

    Pour le refroidissement, no comment...

  12. #402
    Donc on va considerer 130W pour un gulftown et 275W pour un Fermi.
    Il faut probablement une 50aine de watts supplementaires pour faire fonctionner le gulftown (sur la plateforme) en single socket, et 80W en double. Je ne le blinde pas de memoire parce que si il y avait besoin d une telle quantite de memoire Fermi aurait du mal.
    Pour le Fermi il faut 50W de plus pour la plateforme (je suis genereux, le PCIe doit bien consommer avec 4 cartes dessus en train de consommer des donnees aussi vite que possible) plus un CPU au moins un peu actif. Disons 50W.
    J'ai la flemme de chercher des chiffres exacts, mais si qq un veut le faire il est le bienvenu (je ne compte pas l efficacite des etages de power delivery).

    Dual socket gulftown: 260+80 ~= 340W
    Quad fermi: 1100+100 =1200W

    Si on suppose que le dual socket gulftown a un peak FP 3x celui du i920.
    Pour que l'efficacite d un cluster de quad fermi soit equivalente a celle d un cluster de dual gulftown il faut que le flop peak des 4 Fermi soit 3.5x celui du dual Gulftown.
    Donc si un Gulftown est plus performant que 50% d'un Fermi, d'un point de vue power/perf avec mes hypotheses, le cluster a base de CPU est plus efficace. A vue de nez si le Fermi est rentable de ce point de vue la ca ne va pas etre de beaucoup a moins que mes hypotheses soient particulierement erronnees.
    D'un point de vue prix, 1000$/CPU, 1000$ de plus pour une plateforme dual socket, 100$ pour le CPU a mettre avec les GPU, il est possible de construire un cluster a base de Fermi qui coute moins cher de ~30% (si on met 4 fermi / carte mere) pour a peu pres les memes perfs.

    Au final je vois en gros 30% d'avantage pour un cluster a base de Fermi pour quelqu'un qui n'executera que des applications qui tournent bien dessus (mais je pense que celui qui voudrait se monter un cluster de 2000 machines risque d'avoir qq problemes a trouver ses cartes , je sais c'est bas).

    Bien entendu si mes hypotheses de depart sont fausses, mes conclusions aussi.
    fefe - Dillon Y'Bon

  13. #403
    Les ordres de grandeur me semblent bons, à part que les chiffres de départ sont sur du code pas optimisé pour Fermi...

    En vrai les supercalculateurs avec des Fermi dedans ont aussi des Gulftown, pas des procos à 100$, et les benchmarks (ici LINPACK) tournent sur CPU+GPU... Ça ne change pas grand-chose au calcul, mais l'avantage est surtout en densité (les GPU sont presque gratuits en densité, et compétitifs en énergie et prix, si tu as de quoi les refroidir).

    Citation Envoyé par fefe Voir le message
    (mais je pense que celui qui voudrait se monter un cluster de 2000 machines risque d'avoir qq problemes a trouver ses cartes , je sais c'est bas).
    Dans ce genre de cas tu négocies directement à la source pour être servi en priorité.
    Pourquoi tu crois qu'on trouve si peu de GeForce et aucun Tesla dans le channel?
    Spoiler Alert!
    [Coup de bluff]

  14. #404
    Citation Envoyé par Møgluglu Voir le message
    Pourquoi tu crois qu'on trouve si peu de GeForce et aucun Tesla dans le channel?
    Spoiler Alert!
    [Coup de bluff]
    Pas besoin de mettre un spoiler, on sait tous que leurs rendements sont merdiques
    Ati avait déjà du mal avec son die plus petit, alors nvidia avec son die énorme...

    Et j'espère pour eux qu'il n'y a pas de passif dedans, car vu la dispersion de process de ces derniers ça doit pas arranger leurs affaires...

    Tiens d'ailleurs question à tous, il y a des gens qui font du layout numérique (ou rf) ici?
    Jme sens un peu seul ^^'

  15. #405
    Citation Envoyé par hellsing Voir le message
    Tiens d'ailleurs question à tous, il y a des gens qui font du layout numérique (ou rf) ici?
    Jme sens un peu seul ^^'
    Non pas de layout ici, mais il y a quelques personnes qui bossent dans l'industrie du MP qui postent ici.
    fefe - Dillon Y'Bon

  16. #406
    Vu sur RWT, un exemple de CUDA vs OpenCL : http://arxiv.org/abs/1005.2581v1
    Je peux pas dire ce que ca vaut, j'y connais rien

  17. #407
    C'est dommage qu'ils aient pas réussi pensé à l'essayer sur une carte AMD...

    Bon point pour NV, ça confirme la tendence de faire tout le développement et débuggage en CUDA, pour ensuite porter l'appli en OpenCL/CAL.
    En particulier le programme de password cracking pour lequel les Radeon mettent une branlée aux GeForce a été développé comme ça :
    http://www.golubev.com/blog/

  18. #408
    Sinon, il y a aussi ce papier, que j'ai pas lu mais dont on m'a dit beaucoup de mal.
    http://ft.ornl.gov/pubs-archive/shoc.pdf
    Dernière modification par Møgluglu ; 17/05/2010 à 12h48. Motif: Lien PDF

  19. #409
    GF104 : le retour en force du parallélisme d'instructions sur les archi Nvidia?
    http://www.anandtech.com/show/3809/n...the-200-king/2
    http://pc.watch.impress.co.jp/docs/c...12_380148.html

    Ou l'explication de pourquoi leur compilo se faisait chier à scheduler les instructions par paires en bouffant plein de registres au passage...

  20. #410
    Hop un petit hors-sujet...

    Quelqu'un aurait de bonnes references pour convertir du vieux code OpenGL en un truc moderne (en simplifiant : plus de glBegin, glVertex, glFrustum, etc.) ?

  21. #411
    http://www.realworldtech.com/page.cf...2610001641&p=6

    Le reste de l'article vaut le coup aussi.
    fefe - Dillon Y'Bon

  22. #412
    Citation Envoyé par newbie06 Voir le message
    Quelqu'un aurait de bonnes references pour convertir du vieux code OpenGL en un truc moderne ?
    Genre, DirectX ?

    Ok, =>[]

  23. #413
    Citation Envoyé par newbie06 Voir le message
    Quelqu'un aurait de bonnes references pour convertir du vieux code OpenGL en un truc moderne (en simplifiant : plus de glBegin, glVertex, glFrustum, etc.) ?
    Tu penses à de l'OpenGL ES?
    Tu risques d'avoir plus de chance en demandant aux canards sur le forum Software...
    (La dernière fois que j'ai fait de l'OpenGL, il y avait encore plein de glBegin dans mon code. Mais c'est peut-être moi qui suis à la rue aussi... )

  24. #414
    Oui, OpenGL ES 2 et son profil dans OpenGL 4.1. C'est clairement ce qu'il faut faire maintenant
    Et clairement aussi, la quasi-totalite du code existant est tres loin de s'en approcher

  25. #415
    Effectivement plein de gens se plaignent que les comms entre CPU et GPU sont trop lentes et diminuent l'intérêt du GPU. Et ils suggèrent en général l'intégration du GPU dans le CPU comme la solution qui va régler tous les problèmes...

    Sauf que l'avantage de bande passante de x5 du GPU, il devient quoi du coup?
    Ça limite à des applis qui sont limitées uniquement par le calcul ou dont les jeux de données tiennent dans le cache L3, espèce qui me semble en voie de disparition...

  26. #416
    En plus, l'integration du GPU ne risque-t-elle pas aussi de brider la taille du couple CPU/GPU ? Y'a qu'a imaginer la taille d'un Nehalem avec un Fermi en plus et les problemes de dissipation thermique

    Quant a savoir si le (GP)GPU est vraiment beaucoup plus rapide que le CPU, j'ai d'enormes doutes. J'ai regarde 2 articles que nVidia cite comme exemple de speedup >100 et ces articles sont a gerber de mauvaise foi (cf ici et la). Bravo pour l'integrite scientifique

  27. #417
    Citation Envoyé par newbie06 Voir le message
    En plus, l'integration du GPU ne risque-t-elle pas aussi de brider la taille du couple CPU/GPU ? Y'a qu'a imaginer la taille d'un Nehalem avec un Fermi en plus et les problemes de dissipation thermique
    Tant que ce sont 2 dies séparés, ca limite le problème.
    Viendra après un moment ou il sera plus intéressant de diminuer la latence en fusionnant les 2 dies que d'éviter la complexité et le cout que ca représente.
    Je ne me rappelle plus trop des roadmaps Intel et AMD mais les prochaines générations devraient certainement avoir un GPU directement intégré dans le die du CPU. Après, c'est sur que ce ne sera pas un monstre comme Fermi.

  28. #418
    Deux dies, je ne suis pas sur que ca limite beaucoup les problemes de dissipation thermique...

  29. #419
    Citation Envoyé par newbie06 Voir le message
    Quant a savoir si le (GP)GPU est vraiment beaucoup plus rapide que le CPU, j'ai d'enormes doutes. J'ai regarde 2 articles que nVidia cite comme exemple de speedup >100 et ces articles sont a gerber de mauvaise foi (cf ici et la). Bravo pour l'integrite scientifique
    Pfff, ×100 et ×150, c'est pas terrible, moi je fais ×1600 par rapport à du code CPU out-of-the-box.
    (et je sais expliquer pourquoi)

    Le speedup par rapport à la version non-optimisée peut avoir un sens si tu as un vieux code CPU, et que tu veux avoir une idée des ratios speedup / effort de développement qu'impliquerait un portage sur GPU, une optimisation sur multicore, sur cluster, sur Cell/FPGA/etc.

    Genre, je peux avoir ×100 sur GPU en y passant 6 mois, ou ×20 sur CPU en y passant 3 mois, ou ×1,5 si je change rien et j'achète une nouvelle machine, qu'est-ce que je fais?

    Citation Envoyé par Yasko Voir le message
    Viendra après un moment ou il sera plus intéressant de diminuer la latence en fusionnant les 2 dies que d'éviter la complexité et le cout que ca représente.
    Je ne me rappelle plus trop des roadmaps Intel et AMD mais les prochaines générations devraient certainement avoir un GPU directement intégré dans le die du CPU. Après, c'est sur que ce ne sera pas un monstre comme Fermi.
    Ça arrivera très vite pour les laptops et les PC de non-gamers... On a déjà Clarkdale et Arrandale depuis le début de l'année, Sandy Bridge et Llano et Ontario chez AMD devraient arriver sous peu.
    Mais à moyen terme les canards auront toujours leur GPU séparé.

    Et j'ai des doûtes concernant le HPC sur de l'Intel GenX ou de l'AMD Evergreen castré avec 2 canaux de DDR3...
    (surtout qu'avec AVX et le FMA dans Bulldozer, le côté CPU devrait rattraper pas mal de la différence)
    Dernière modification par Møgluglu ; 09/08/2010 à 14h09.

  30. #420
    Citation Envoyé par Møgluglu Voir le message
    Pfff, ×100 et ×150, c'est pas terrible, moi je fais ×1600 par rapport à du code CPU out-of-the-box.
    (et je sais expliquer pourquoi)
    Je vois deux possibilites : ton probleme tient en cache GPU mais pas CPU, ou bien tu utilises les unites de rasterization. Sinon, je ne te crois pas
    J'ose meme pas imaginer que tu aurais ose compiler ton code en -O0 ou que ton CPU est un Atom.
    Le speedup par rapport à la version non-optimisée peut avoir un sens si tu as un vieux code CPU, et que tu veux avoir une idée des ratios speedup / effort de développement qu'impliquerait un portage sur GPU, une optimisation sur multicore, sur cluster, sur Cell/FPGA/etc.

    Genre, je peux avoir ×100 sur GPU en y passant 6 mois, ou ×20 sur CPU en y passant 3 mois, ou ×1,5 si je change rien et j'achète une nouvelle machine, qu'est-ce que je fais?
    Je suis assez d'accord. Cependant certaines optims sont valables sur les deux. Par exemple, la parallelisation. Ou bien l'utilisation de precision simple.

    Mais, je n'en demords pas, les deux articles sont de purs mensonges indignes d'un article scientifique, c'est plus du marketing qu'autre chose et de mon point de vue ca discredite la communaute GPGPU pour un mec comme moi qui n'y connait pas grand-chose. C'est un peu comme si je m'amusais a benchmarker un Atom contre un A9 en oubliant de forcer l'utilisation de SSE au lieu de x87, ce serait malhonnete et "misleading".

Page 14 sur 22 PremièrePremière ... 4678910111213141516171819202122 DernièreDernière

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
  •