Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 13 sur 19 PremièrePremière ... 35678910111213141516171819 DernièreDernière
Affichage des résultats 361 à 390 sur 567

Discussion: Intel et Larrabee

  1. #361
    À 80 cores c'est pas plutôt Terascale/Polaris ? On a vu un die-shot de Larrabee avec 32 cores...

  2. #362
    Oui ca ressemble a une typo .

    C'est combien le max atteint sur SGEMM sur les GPUs actuels (ou futurs si qq un a acces a un Fermi )
    Dernière modification par fefe ; 19/11/2009 à 00h17.
    fefe - Dillon Y'Bon

  3. #363
    Citation Envoyé par fefe Voir le message
    C'est combien le max atteint sur SGEMM sur les GPUs actuels (ou futurs si qq un a acces a un Fermi )
    Chez NV, on est a 60% du peak (MAD seuls) sur GT200, donc 425 Gflops sur GTX 285.

    Côté AMD, on aurait des prototypes atteignant 880 Gflops sur 4870 (73% peak). Si ça scalait linéairement, on s'approcherait de 2 Tflops sur 5870, mais les ratio Tex/FPU et débit LDS/FPU fait que l'implémentation "optimale" devra être différente...

    Pour Fermi, on aura 1 instruction load 128-bit pour 4 instructions FMA. Si les loads sont gérés par l'unité dédiée, on atteindra maxi 80% du peak (limitation au niveau du dispatch).
    Ça doit donner une fourchette de 730 à 1000 Gflops sur Tesla C2050...

  4. #364
    Ok donc pour l'instant c'est la demo la plus "haute" sachant que d'ici quelques mois des produits devraient en arriver la (pas des prototypes).
    fefe - Dillon Y'Bon

  5. #365

  6. #366
    Oh surprise ...
    fefe - Dillon Y'Bon

  7. #367
    Je ne suis vraiment pas surpris, je n'ai jamais cru au modèle cohérent avec plein de coeurs, je trouve l'idée du message passing tellement plus intéressante (au moins ça me rappelle ma jeunesse ).

  8. #368
    Larabee ne sortira pas ?
    Encore une victoire de canard : http://forum.canardpc.com/showpost.p...2&postcount=30
    (Y'avait un autre exemple plus pertinent avec une comparaison avec l'itanium 1 tout pourri fourni aux dev pour passer en itanium 2 performants ensuite, mais j'ai la flemme de chercher)
    Suite à une suggestion, je vais utiliser cette signature pour des canards en manque de ranking pro. Ou des quotes idiots.

  9. #369
    Aussi souple soit il, Larrabee ne pouvait clairement pas rivaliser avec la concurrence en terme de performance brute. En allant titiller le marché 3D des API graphiques Intel ne pouvait de toute façon pas espérer bcp mieux qu'un échec cuisant sur le haut de gamme.

    Du côté du ray-tracing, leur démo de l'IDF dernier était loin de pouvoir faire la différence avec le ray-tracing sur GPU plus traditionnel. Il leur reste alors le calcul haute performance, ce sur quoi ils n'ont rien à mettre en face d'un NVidia qui fagocite le domaine.

    Bref l'annulation du Larrabee n'est clairement pas une surprise.

    Un avenir viable pour du graphique haut de gamme Intel? Pourquoi pas si le rendu software réussi à s'imposer à nouveau (fort probable). Plus d'API graphique => plus de standard de "GPU". Dans ce cas de figure, un "CPU"-like peut faire tout aussi bien (mieux?) qu'un GPU sur du code graphique, et ce que ce soit sur un CPU externalisé sur carte (Larrabee 2, Fermi3 ) ou sur un CPU classique...

  10. #370
    D'après cette news (d'accord c'est Fudzilla ) ,Intel dément stopper Larrabee comme solution graphique et travaille jusqu'au moment ou il sera à niveau de Nvidia/Amd .

  11. #371
    Ce n'est pas que Fudzilla, c'est le message officiel d'Intel, et c'est logique : ils ont besoin de Larrabee et ne vont pas abandonner comme ça.

  12. #372
    Ca serait con d'investir autant dans un concept et de s'arreter alors que le premier chip n'est pas satisfaisant (surtout que historiquement aucun chip complexe n'a delivre ce qui etait attendu de lui a la premiere generation). Donc ils continuent, je dirais que jusqu'a present tout va normalement, on saura vraiment ce que vaut Larrabee a la 2 eme ou 3 eme generation, ceux qui ont cru autrement sont ceux qui ecoutent les voix de marketing .
    fefe - Dillon Y'Bon

  13. #373
    Alors j'espère que les générations 2 et 3 auront le bon goût de ne pas être cohérentes.

  14. #374
    Tout à fait d'accord ,ce n'est pas une tentative pour creer un nouveau marché (ce qui permet d'avoir une plus grande marge de manoeuvre) mais essayer de pénétrer un marché très compétitif (et en évolution très rapide) et bipolaire (Amd-Nvidia) .

    Donc pour réussir à avoir un produit viable ,ils doivent réussir à concevoir une puce performante ,pas trop complexe à produire et à programmer et sans exploser la dissipation thermique ,ce qui leur demandera quelque génération (le moins possible espérons-le) pour obtenir un résultat probant

  15. #375
    Citation Envoyé par Tim Sweeney
    I see the instruction set and mixedscalar/vector programming model of Larrabee as the ultimate computingmodel, delivering GPU-class numeric computing performance and CPU-classprogrammability with an easy-to-use programming model that willultimately crush fixed-function graphics pipelines. The model will berevolutionary whether it's sold as a Express add-in card, an integratedgraphics solution, or part of the CPU die.

    To focus on Teraflops misses a larger point about programmability:Today's GPU programming models are too limited to support large-scalesoftware, such as a complete physics engine, or a next-generationgraphics pipeline implemented in software. No quantity of Teraflopscan compensate for a lack of support for dynamic dispatch, a full C++programming model, a coherent memory space, etc.

  16. #376
    whether it's sold as a Express add-in card, an integratedg raphics solution, or part of the CPU die.
    Sold is the word .
    fefe - Dillon Y'Bon

  17. #377
    Bah s'il veut la cohérence à tous les niveaux, j'espère qu'il est prêt à éduquer tous ses programmeurs sur les méfaits de laisser faire ça sur un système avec un ringbus

    Je trouve son discours limite fanboy, même si je suis plutôt d'accord avec certains points.

  18. #378
    Tu peux en dire plus sur ces mefaits ? Je ne vois pas de quoi tu veux parler...
    fefe - Dillon Y'Bon

  19. #379
    Hum, je me demande s'il y a un piège

    Exemple bête : je génère une texture procédurale sur P0. Cool avec la cohérence, tout le monde voit les données et peut faire ce qu'il veut avec cette texture ; enfin pas tout à fait, si je dois la modifier, chuis pas con je la locke avec un sémaphore, mais tout le monde peut la lire. Voilà j'ai stupidement saturé le ring bus parce que j'ai x processeurs qui vont lire la texture.

    OK l'exemple est complètement idiot. Mon point est juste que si le placement de données n'est pas fait correctement (impliquant aussi que le traitement est placé), ça ne marche juste pas avec beaucoup de coeurs. Donc la cohérence ne m'apporte pas tant que ça (sauf peut-être des prises de sémaphore plus rapides).

    Idiot ?

  20. #380
    Bien sur que c'etait un piege , mais bon je n'etais pas sur de ce a quoi tu faisais reference.

    Je pense que tu confonds coherence et consistance memoire ou alors oublie le snoop filtering et ce qui est fait de maniere generale pour traiter le trafic de coherence. La coherence est juste le fait de garantir quand tu lis une donnee que tu as la derniere version qui a ete ecrite par qui que ce soit dans le systeme. Tu as des snoop filter qui te permettent de ne snoop que si la donnee a ete demandee pour ecrire par un autre core depuis que tu as obtenu ta derniere copie, donc tu n'emets pas de snoops a chaque lecture, et une fois que ta donnee a ete modifiee il y a plein d'algorithmes intelligents de mise a jour de tes filtres qui reduisent/font disparaitre le risque de passer son temps a snoop pour rien a chaque nouvelle lecture. Qui plus est un snoop est une requete specifique et non un transfert de donnee, ce qui dans la plupart des reseaux d'interconnection transite sur des fils differents geres separement. Bien entendu si tu as une donnee a transferer ca prendra de la bande passante, mais il aurait fallu le faire de toutes facons. Donc oui le traffic de coherence prend de la bande passante, sur le reseau charge de gerer ca qui est optimise pour.

    Si pour des raisons de consistance tu passes ton temps a locker/unlocker des donnees tes perfs vont s'effondrer si beaucoup de monde doit y acceder, mais c'est essentiellement un mauvais algorithme de parallelisation et pas un effet de la coherence. Le fait de travailler sur des tiles de memoire a tendance a simplifier cet aspect considerablement.

    Les problemes de bande passante des ringbus est plus leur scalabilite qu'autre chose. ATI a abandonne le ringbus quand ils ont du mettre trop d'agents dessus, et ils n'etaient absolument pas coherents.

    De maniere generale la simplicite de programmation qu'induit la coherence libere du temps pour reflechir a l'algorithme et au placement des taches .
    fefe - Dillon Y'Bon

  21. #381
    Des nouvelles du Siggraph Asia en VO :
    http://pc.watch.impress.co.jp/docs/c...22_338322.html

    La roadmap initiale :
    À partir de Larrabee 1 en 2010, sortie d'une nouvelle version chaque année (2, 3, 4).
    En 2014, intégration du core LRB dans les CPU mainstream.

    C'est finalement Larrabee 2 qui introduira une incompatibilité dans le jeu d'instruction, même si ça n'a pas l'air de changer grand-chose pour le programmeur sur les instructions vectorielles. Enfin si jamais il n'est pas annulé entre temps.

    Fermi n'est pas l'ennemi de Larrabee, c'est un allié.
    Bah ouais, il contribue à faire migrer les moteurs de jeu depuis les API graphiques vers du rendu soft et de la physique, terrain favorable à LRB...
    AMD devrait suivre d'ici-là.

  22. #382
    Marrant a chaque fois qu'ils ont annonce une roadmap ils s'en sont mordu les doigts. Par exemple, comparez cette annonce a la rumeur de Charlie: http://www.semiaccurate.com/2009/08/...graphics-cpus/ .
    fefe - Dillon Y'Bon

  23. #383
    Citation Envoyé par Møgluglu Voir le message
    C'est finalement Larrabee 2 qui introduira une incompatibilité dans le jeu d'instruction, même si ça n'a pas l'air de changer grand-chose pour le programmeur sur les instructions vectorielles.
    J'ai une question à la con : incompatibilité jusqu'à quel point ? Ne serait-ce pas l'occasion pour Intel de laisser tomber certaines features qu'ils se trainent depuis 30 ans et qui ont un coût astronomique (cf. le post de fefe) ? Après tout, la compatibilité binaire on s'en tape un peu sur LRB, non ?

  24. #384
    Ils parlent d'ncompatibilite sur des instructions qui n'existent pas en x86 mais avaient ete introduites par LRB1. Vu que LRB1 ne sera fourni qu'en samples a quelques developpeurs, c'est comme dire que le jeu d'instruction de LRB1 n'a jamais existe... et que LRB2 a le seul jeu d'instruction LRB... Je doute que le sacrifice de la legacy x86 soit pres d'arriver .
    fefe - Dillon Y'Bon

  25. #385
    Ha ça ne concerne que les instructions vectorielles. Je suis bien déçu
    Quelle est la justification pour conserver les aberrations de l'ISA x86 ? Niveau compilo ce serait facile de changer. J'imagine donc qu'il s'agit de réutiliser des unités existantes ?

  26. #386
    X86 c'est comme une religion, il ne faut pas poser ce genre de questions, sinon tu risques de ne pas aimer la reponse
    fefe - Dillon Y'Bon

  27. #387
    Citation Envoyé par newbie06 Voir le message
    Ha ça ne concerne que les instructions vectorielles. Je suis bien déçu
    Pire que ça, la partie vectorielle n'aurait quasiment pas changé non plus.

    Peut-être un changement de l'encodage des instructions pour se rapprocher d'AVX, une mise à la norme IEEE 754-2008 des instructions flottantes ou ce genre de chose...

  28. #388
    Option 1 est plus proche de la realite qu'option 2 a mon avis. Des fois il y a des gens qui ne reflechissent pas au futur quand ils definissent une ISA...
    fefe - Dillon Y'Bon

  29. #389
    Citation Envoyé par fefe Voir le message
    X86 c'est comme une religion, il ne faut pas poser ce genre de questions, sinon tu risques de ne pas aimer la reponse
    Beuh je ne vois pas ce que je pourrais moins aimer que le x86 actuel
    J'adore les incohérences sur les mise à jour des flags, qui obligent à considérer chaque flag comme un registre. Ca doit être un bonheur pour les designers...

    Décidément j'y comprends rien au marketing

  30. #390
    Bill Kircos à propos du projet Larrabee (et de leur futurs IGP) :
    http://blogs.intel.com/technology/20...phics-rela.php

Page 13 sur 19 PremièrePremière ... 35678910111213141516171819 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
  •