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...
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...
J'ai pas reussi a me faire payer le billet, il y a qq representants de mon equipe par contre .
fefe - Dillon Y'Bon
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.
Passe le bonjour a Aamer de ma part (le type avec la politique de remplacement), il est sympa.
fefe - Dillon Y'Bon
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.
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 à 20h25.
fefe - Dillon Y'Bon
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...
Je pense aussi, il n'y a pas de mythe à casser parce que personne n'en a aucune idée.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.
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. )
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
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?...
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...)
Ç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.
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.
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é.
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.
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
J'ai mis longtemps avant de comprendre que vous parliez d'unrolling. Vous pourriez pas parler comme fefe, non?
C'est vrai, mais la phrase exactement opposée aussi :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
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...
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 à 21h20.
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
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…
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
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...
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
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:
Si jeu de mot il y a, il est bien trop subtil pour moi...
http://d.hatena.ne.jp/grayfox/mobile?date=20041007