Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 6 sur 9 PremièrePremière 123456789 DernièreDernière
Affichage des résultats 151 à 180 sur 267

Discussion: Micro-Architecture

  1. #151
    Bon, j'ai réussi à trouver de quoi me payer un billet de train pour aller à ISCA.
    Je posterai ici si je vois des trucs intéressants (ou si j'ai des questions...)

    En attendant, le programme...

  2. #152
    J'ai pas reussi a me faire payer le billet, il y a qq representants de mon equipe par contre .
    fefe - Dillon Y'Bon

  3. #153
    Je suis pas un habitué donc je saurais pas dire ce qui est nouveau et ce qu'on voit passer chaque année depuis 15 ans, mais les sujets du jour sont :

    - Des archis clusterées "scalables" (configurable dynamiquement entre des cores in-order single-issue basse performance et du 4-issue out-of-order haute conso).

    - De l'exploration d'espace de paramètres en optimisant le compromis perf/conso.
    Et si on prend en compte la tension d'alimentation en plus, l'espace des choix architecturaux pertinents pour minimiser la conso devient tout petit : faut faire du 2-issue in-order ou 2-issue ooo, en dessous ou au dessus autant jouer sur la tension... (au moins avec les process actuels...)

    - Des slides en Comic Sans MS chez Intel, et des blagues pas droles chez Microsoft. (Znokiss il bosse chez MS Research en fait )

    - Des caches de tables de pages (en plus mieux qu'avant, parait-il).

    - Une politique de remplacement de cache pour réduire la pollution par les données non-temporelles.

    - Un mécanisme de write-back du dernier niveau de cache qui tient compte de la DRAM qui est derrière (regrouper les écritures dans la même page toussa).

    - Des codes correcteurs pour réduire la fréquence de refresh des eDRAM (et réduire la conso).

    - Des mémoires à changement de phase, ça a l'air (encore) à la mode. Du wear-leveling, et des cellules reconfigurables entre SLC et MLC, pour ajuster le compromis capacité/latence.

    - Des caches sur SSD pour gros serveurs de bases de données.

    - Des DRAM basse-conso (et haute-latence).

    - Des connexions optiques on-chip, ça a l'air à la mode aussi.

  4. #154
    Passe le bonjour a Aamer de ma part (le type avec la politique de remplacement), il est sympa.
    fefe - Dillon Y'Bon

  5. #155
    Citation Envoyé par fefe Voir le message
    Passe le bonjour a Aamer de ma part (le type avec la politique de remplacement), il est sympa.
    Trop tard.
    Mention spéciale à la SNCF qui a obligé tout le monde à partir avant la fin, a renforcé les clichés que les Américains ont sur la France et m'a fait rater un des talks les plus intéressants de la conf :
    le papier d'Intel : "Debunking the 100X GPU vs. CPU Myth: An Evaluation of Throughput Computing on CPU and GPU"

    Ils comparent les perfs sur Core i7 960 et GTX 280 de plusieurs noyaux de calcul très optimisés de chaque côté, et obtiennent un speedup moyen de 2,5 en passant sur GPU.
    Le papier analyse ensuite les bottlenecks de chaque archi et les conséquence sur la programmation et l'archi.
    Très bonne analyse objective qui devrait contribuer à réduire le nombre de papiers "speedup GPU x100" à l'avenir...

    La réponse de la propagande de NV n'a pas tardé :
    http://blogs.nvidia.com/ntersect/201...ays-intel.html

    Au delà du PR bullshit standard, ils ont raison de dire que le mythe, c'est que les GPU seraient plus complexes à programmer que les CPU multicores-SIMD actuels.

    Par exemple le papier d'Intel oublie soigneusement de parler du SIMT vs SIMD au titre des différences GPU/CPU. Alors que ça a à mon avis un impact assez énorme sur le travail qui est réclamé au compilateur et au programmeur.

  6. #156
    J'ai vu une presentation de ce papier a une conf il y a 2 semaines . C'est effectivement un bon papier, il conclue encore a des speedups tres raisonables pour les GPUs (ce qui evite de penser que c'est juste du marketing pro CPU).

    La presentation d'apres a cet conf etait: debunking the myth that CPU are easier to program than GPU (et venait de la meme boite ).

    Leur analyse manque malheureusement de la dimension power/energy qui est un autre axe fondamental quand on cherche a comparer les perfs de systemes a base de CPU ou GPGPU. Je ne sais mas si il y a un mythe ni meme precisement ou ce situe quoi.
    Dernière modification par fefe ; 24/06/2010 à 21h25.
    fefe - Dillon Y'Bon

  7. #157
    Citation Envoyé par fefe Voir le message
    La presentation d'apres a cet conf etait: debunking the myth that CPU are easier to program than GPU (et venait de la meme boite ).
    Bon, ça va alors.

    Après, si on considère un CPU avec un jeu d'instruction SIMD orthogonal avec prédication et gather-scatter genre Larrabee et un très bon compilateur, la différence en programmabilité ne devrait plus être significative...

    Leur analyse manque malheureusement de la dimension power/energy qui est un autre axe fondamental quand on cherche a comparer les perfs de systemes a base de CPU ou GPGPU. Je ne sais mas si il y a un mythe ni meme precisement ou ce situe quoi.
    Je pense aussi, il n'y a pas de mythe à casser parce que personne n'en a aucune idée.
    Dans l'immédiat, les problèmes de power à régler avec les GPU actuels sont au niveau plate-forme. Ça reste surtout du on/off pour l'instant...
    Mais déterminer quand on peut diminuer les fréquences GPU/GDDR sans que ça affecte les perfs n'est pas évident : le calcul GPU peut aussi bien être sur le chemin critique que totalement masqué par un thread CPU... Donc il faut des politiques de gestion de l'énergie coordonnées sur tout le système.
    (Mais je soupçonne que tu connais tout ça bien mieux que moi. )

  8. #158
    Citation Envoyé par Møgluglu Voir le message
    Après, si on considère un CPU avec un jeu d'instruction SIMD orthogonal avec prédication et gather-scatter genre Larrabee et un très bon compilateur, la différence en programmabilité ne devrait plus être significative...
    Je croyais que le point critique était la gestion efficace de la hiérarchie mémoire, et là pas de miracle, c'est à la bite et au couteau sur un CPU.

  9. #159
    orthogonal, predication, gather, scatter, que les mots cles qui vont bien, oh et puis un compilateur miracle en passant. J'hesite a me tirer une balle maintenant tout de suite ou plus tard.

    Le jeu d'instruction de Larrabee 1 est assez loin de ca...

    Le power management des GPU est encore a ses balbutiements, alors en plus le faire pour du GGPGPU... C'est un bon sujet de recherche .
    fefe - Dillon Y'Bon

  10. #160
    Citation Envoyé par newbie06 Voir le message
    Je croyais que le point critique était la gestion efficace de la hiérarchie mémoire, et là pas de miracle, c'est à la bite et au couteau sur un CPU.
    J'avais hésité à le mettre en pensant à toi.
    Je n'ai pas la moindre idée des performances qu'aurait une appli programmée "à la GPU", mettons en OpenCL avec la mémoire locale managée à la main, une fois portée sur un CPU avec un compilateur décent.
    Ça sera sous-optimal, c'est sûr, mais de combien?...

    Citation Envoyé par fefe Voir le message
    orthogonal, predication, gather, scatter, que les mots cles qui vont bien, oh et puis un compilateur miracle en passant. J'hesite a me tirer une balle maintenant tout de suite ou plus tard.

    Le jeu d'instruction de Larrabee 1 est assez loin de ca...
    On nous aurait menti?

    Un truc qui m'a toujours étonné :
    Intel fait aujourd'hui des processeurs x86 superscalaires qui font tout en dynamique, mais se lance dans des projets qui dépendent uniquement du compilateur où tout est fait en statique. Mais en conservant le x86.
    NVIDIA a tout une pile logicielle avec un driver opaque et un JIT pour recompiler quand ils veulent, et ils conçoivent leurs ISA comme si elles devaient durer 30 ans et se contentent d'un compilateur simpliste.
    Il y a pas un paradoxe là?

    (je suppose qu'il y a des choses qu'il ne vaut mieux pas chercher à comprendre...)

  11. #161
    Citation Envoyé par fefe Voir le message
    orthogonal, predication, gather, scatter, que les mots cles qui vont bien, oh et puis un compilateur miracle en passant. J'hesite a me tirer une balle maintenant tout de suite ou plus tard.

    Le jeu d'instruction de Larrabee 1 est assez loin de ca...
    </p>
    On parle bien d'x86 ?

    ---------- Post ajouté à 12h07 ----------

    Citation Envoyé par Møgluglu Voir le message
    Un truc qui m'a toujours étonné :
    Intel fait aujourd'hui des processeurs x86 superscalaires qui font tout en dynamique, mais se lance dans des projets qui dépendent uniquement du compilateur où tout est fait en statique. Mais en conservant le x86
    Ben tu fais en 2 temps : implémentation en soft (compilateur) puis mise en "hard" (JIT hardware des core 2 et i7)
    Mes propos n'engagent personne, même pas moi.

  12. #162
    Citation Envoyé par Neo_13 Voir le message
    Ben tu fais en 2 temps : implémentation en soft (compilateur) puis mise en "hard" (JIT hardware des core 2 et i7)
    Ça ressemblerait plutôt à du Transmeta Crusoe alors...
    L'approche est quand même très différente entre des optimisations dynamiques et des optimisations statiques.

    Un compilo est capable d'analyser des dépendances très loin dans le code, il connait la durée de vie des variables, il comprend la structure du contrôle, et il peut la changer profondément, il peut vectoriser... Des trucs très difficiles à faire dans un CPU qui voit passer juste une fenêtre d'instructions...

    Par contre le compilo va galérer à identifier des effets dynamiques comme l'aliasing de pointeurs, les régularités dans les branchements, dans les accès mémoire... Alors que dynamiquement c'est zéro chouchaï.

    Les deux ont leurs avantages et leurs inconvénients, et je ne pense pas qu'il y ait beaucoup de mécanismes qu'on puisse conserver tels quels entre statique et dynamique... C'est le débat classique superscalaire vs. VLIW.
    La dernière tentative en date de mixer les deux approches, ça s'appelait l'IA-64.

  13. #163
    Pour moi, les core 2 ont en partie cette approche : le compilateur fait de l'optimisation, sur un certain nombre de point, mais le cpu fait quasiment du jit en hard, quand il décide de dépiler des boucles, d'assembler des µop, des op, de rename des registres (qu'il a en nombre équivalent à ia64, juste c'est le cpu qui décide comment il s'en sert, pas le compilateur)... bref on est loin d'une simple exécution, et même qu'un ooo.
    Mes propos n'engagent personne, même pas moi.

  14. #164
    L'idée, c'est que si ces optimisations sont si efficaces c'est parce qu'elles profitent d'informations qui ne sont connues qu'à l'exécution et sont très dures à prédire avant : genre les directions de branchements, la désambiguation des load/stores...
    C'est bien du tout dynamique.

    Après, tu peux avoir des JIT en soft qui font de l'instrumentation ou de la spéculation pour s'adapter aux phénomènes dynamiques, aussi bien que du JIT en hard/firmware qui te fait un peu d'analyse statique dans le CPU comme Transmeta...

    Mais jusqu'ici le succès de ce genre d'approche hybride a été... limité.

  15. #165
    Core 2
    Core i7

    Ce qu'on y trouve me parait être les premiers pas en termes d'hybridation. Mais je me dis que les premiers qui ont connu l'ooo se sont dit la même chose aussi.
    Mes propos n'engagent personne, même pas moi.

  16. #166
    Hu ? Comparer ce que font les Core2 et les i7 à du JIT faut soit oser, soit ne pas savoir jusqu'où les JIT actuels vont.

    OK taunt à moitié gratuit

    Certains JIT font des analyses qui ne seront jamais possibles sur un CPU, jamais.

    De ce que j'en sais, les micro ops et autres fusions de micro ops sont plutôt similaires à du peephole dans un compilo.

    Quant au dépliage de boucle dans ces CPU je demande à voir. Je pense que c'est juste un buffer qui se trouve entre la i-cache et le coeur. C'est surtout là pour gagner du power. Le dépliage est surtout utile statiquement pour spécialiser les itérations dépliées, factoriser les opérations liées au contrôle de boucle (i++ -> i+=4 si on déplie 4 fois) et mieux scheduler. Hé ouai ces monstres de CPU soit disant OoO ont une vision limitée des dépendances.

    Donc inutile de rêver, certes les CPU modernes sont de plus en plus malins, mais ils n'arriveront jamais au niveau d'un JIT même modérément performant. Ce n'est matériellement ni possible, ni rentable

  17. #167
    Citation Envoyé par newbie06 Voir le message
    Quant au dépliage de boucle
    J'ai mis longtemps avant de comprendre que vous parliez d'unrolling. Vous pourriez pas parler comme fefe, non?

    Donc inutile de rêver, certes les CPU modernes sont de plus en plus malins, mais ils n'arriveront jamais au niveau d'un JIT même modérément performant. Ce n'est matériellement ni possible, ni rentable
    C'est vrai, mais la phrase exactement opposée aussi :
    Donc inutile de rêver, certes les JIT modernes sont de plus en plus malins, mais ils n'arriveront jamais au niveau d'un superscalaire ooo même modérément performant.
    Sinon on aurait tous des VLIW avec un JIT x86.

    Va essayer de prédire les branchements avec 97% de succès avec ton JIT...

  18. #168
    Je parlais évidemment des techniques avancées utilisées par les JIT.

    Je n'ai jamais dit que les prédictions de branchement pouvaient être virées ou que l'OoO était inutile. Je dis juste que ce qu'on peut faire en soft va beaucoup plus loin c'est tout.

    Puis tiens les optims PGO gagnent, tu t'es demandé pourquoi ?

    EDIT : pour clarifier ci-dessus : va beaucoup plus loin et est complémentaire de qu'on peut réaliser en HW
    Dernière modification par newbie06 ; 25/06/2010 à 22h20.

  19. #169
    Citation Envoyé par Møgluglu Voir le message
    Va essayer de prédire les branchements avec 97% de succès avec ton JIT...
    Sur Linpack, no problemo .
    fefe - Dillon Y'Bon

  20. #170
    Citation Envoyé par Møgluglu Voir le message
    Trop tard.
    Mention spéciale à la SNCF qui a obligé tout le monde à partir avant la fin, a renforcé les clichés que les Américains ont sur la France et m'a fait rater un des talks les plus intéressants de la conf :
    le papier d'Intel : "Debunking the 100X GPU vs. CPU Myth: An Evaluation of Throughput Computing on CPU and GPU"

    Ils comparent les perfs sur Core i7 960 et GTX 280 de plusieurs noyaux de calcul très optimisés de chaque côté, et obtiennent un speedup moyen de 2,5 en passant sur GPU.
    Le papier analyse ensuite les bottlenecks de chaque archi et les conséquence sur la programmation et l'archi.
    Très bonne analyse objective qui devrait contribuer à réduire le nombre de papiers "speedup GPU x100" à l'avenir...

    La réponse de la propagande de NV n'a pas tardé :
    http://blogs.nvidia.com/ntersect/201...ays-intel.html

    Au delà du PR bullshit standard, ils ont raison de dire que le mythe, c'est que les GPU seraient plus complexes à programmer que les CPU multicores-SIMD actuels.
    http://www.realworldtech.com/page.cf...WT070510142143

    Un autre cas de comparaison de perf entre 2 archis ou le niveau d'optimization n'est pas comparable entre les 2... (C'est le moins que l'on puisse dire).
    fefe - Dillon Y'Bon

  21. #171
    Il était temps que quelqu'un fasse un article détaillé comme celui-ci sur PhysX. Si David Kanter était en face de moi, je pourrais lui faire des bisous…

  22. #172
    Citation Envoyé par fefe Voir le message
    http://www.realworldtech.com/page.cf...WT070510142143

    Un autre cas de comparaison de perf entre 2 archis ou le niveau d'optimization n'est pas comparable entre les 2... (C'est le moins que l'on puisse dire).
    Clairement honteux. Mais tout le monde fait pareil, donc aucune surprise, n'est-ce pas ?

    D'un point de vue technique, il n'y vraiment aucune raison d'utiliser du x87 :
    - les lib C/C++ natives peuvent etre compilees avec la bonne option
    - s'il y a un generateur de code dynamique, qu'on ne vienne pas me dire qu'il est plus facile de generer du x87 que du SSE
    - pour l'assembleur, c'est comme pour le JIT, il est plus facile de faire du SSE, mais ca necessiterait plus de boulot.

    Le seul frein est peut-etre que la quasi-totalite du code CPU vient d'Ageia directement, et que nVidia ne veut evidemment pas investir dans du developpement... Aux editeurs de jeu de faire pression peut-etre

  23. #173
    Aux éditeurs de jeu d'utiliser Havok ou Bullet Physics plutôt…!

  24. #174
    Ce qui serait intéressant, ça serait d'avoir une idée des perfs respectives de :
    - la version CPU x87,
    - la version CPU compilée en SSE scalaire,
    - la version CPU vectorisée et multithreadée correctement,
    - la version CUDA compilée pour multi-core + SSE,
    - la version CUDA sur GPU NVIDIA,
    - la version CUDA sur GPU AMD...

    Je prend les paris pour le match x87 vs. CUDA sur CPU...

  25. #175
    Citation Envoyé par Alexko Voir le message
    Aux éditeurs de jeu d'utiliser Havok ou Bullet Physics plutôt…!
    Tu garantis que ces libs sont bien optimisees pour les CPU ? Et pour tous les CPU ? Genre Havok sur AMD ? Ou que Bullet Physics est aussi bien optimise sur tous les CPU qu'il l'est pour la PS3 ?

  26. #176
    Citation Envoyé par newbie06 Voir le message
    Tu garantis que ces libs sont bien optimisees pour les CPU ? Et pour tous les CPU ? Genre Havok sur AMD ? Ou que Bullet Physics est aussi bien optimise sur tous les CPU qu'il l'est pour la PS3 ?
    Ah non moi, je garantis rien… :D Mais je suis à peu près sûr que Havok tourne mieux sur les CPU AMD que PhysX. Quant à Bullet, ma foi, c'est Open Source…

  27. #177
    Disons que tout code optimise pour un CPU intel qui n'a pas de if CPUID=AMD (ce qui ne devrait plus etre le cas depuis les incidents de l'epoque P4) sera raisonablement bien optimise sur AMD. Il y aura peut etre quelques % a regagner en optimisant specifiquement pour le CPU AMD, mais le gros de l'optim sera deja fait si tu est multithreade et si tu supportes SSE packed... (Bien entendu l'inverse est vrai aussi).
    fefe - Dillon Y'Bon

  28. #178
    Question hors-sujet mais néanmoins débile :
    dans le titre du papier de Patterson, Latency lags bandwith, il y a un jeu de mots subtil caché ou bien c'est juste une typo?

    :mecquifaitsabiblio:

  29. #179
    Si jeu de mot il y a, il est bien trop subtil pour moi...

    http://d.hatena.ne.jp/grayfox/mobile?date=20041007

  30. #180
    C'est ce qu'il me semblait aussi...

    Le bloggeur japonais se pose la même question.

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
  •