Brice Goglin a écrit 181 commentaires

En ayant un gros calculateur petaflopique plutot que plein de teraflopiques, tu factorises plein de couts.

Que tu dises "en dehors des armes nucleaires, je vois pas l'interet", OK. En dehors la crypto, admettons. Par contre la climato c'est utile pour la société. Et les prévisions météo a plus court terme sont également capables d'utiliser des puissances de calcul colossales, ils suffit d'augmenter la précision et/ou la durée de prédiction. Il y a plein d'applis qui sont capables d'utiliser de telles puissances sans forcément avoir des buts malveillants.

Ce matin, à supercomputing, il y avait par exemple une présentation parlant de simulations du cerveau humain (http://sc12.supercomputing.org/schedule/event_detail.php?evid=inspkr103). En gros, pour savoir si on comprend bien comment ca marche (puis essayer de le guérir), on va simuler ce qu'on a compris. Sauf qu'il faut un exaflop/s pour faire ça apparemment, donc 100 fois les plus gros supercalculateurs actuels…

Les avancées concrètes dues au HPC, y en a partout dans la société moderne, vu que la simulation numérique est partout:
* Les prévisions météo sont passées de 5 à 7 il y a quelques années
* On sait faire des batiments antisismiques (pas facile de tester grandeur nature, la simu numérique est la seule solution pour ça)
* On concoit des voitures plus solides en les modélisant numériquement (et en les crash-testant numériquement)
Tous les trucs que les ingénieurs faisaient avant en resolvant des grosses équations qui font mal à la tête, en physique mais pas que…

Toutes ses grosses machines ont des batchs schedulers dans lesquels les utilisateurs peuvent préciser combien de coeurs de CPUs et combien de GPUs et coeurs ils veulent (voire aussi combien de mémoire). Pas vraiment de problème technique de ce coté, si ce n'est l'impossibilité de partager un GPU. On sait très bien mettre un processus utilisant deux coeurs et deux GPUs en même temps qu'un processus utilisant les autres coeurs et du MPI.

Par contre des fois les utilisateurs ont peur de se faire marcher dessus par les voisins (par exemple si tu partages un cache ou un banc mémoire), donc ils peuvent appliquer des contraintes genre "file moi un noeud entier même si j'ai demandé qu'un seul coeur, je veux être tranquille".

Euh, je sais pas de quand date ton bus PCI, mais les ordres de grandeurs entre PCIe et RAM ne sont pas du tout aussi grands. Ce qui est compliqué c'est qu'il y a plusieurs moyens de faire les transferts, et il faut bien choisir selon la taille des données et selon si c'est la latence ou le débit qui t'intéresse. Mais quand c'est bien implémenté, le rapport des perfs entre RAM et PCIe n'est que de l'ordre de 3 ou 4 en débit et 5-10 en latence. Un GPU sur PCIe 3.0 16x, c'est de l'ordre de 10Go/s en DMA, et moins d'1 microsecondes en latence. Que NVIDIA ait implémenté ça n'importe comment est un autre problème :) Mais comme on utilise souvent des gros jeux de données, et que les gens commencent à bien savoir qu'il vaut mieux faire des gros transferts plutot que plein de petits, c'est surtout le débit qui compte.

Ok tu parles de faire cohabiter les modèles dans un même code, pas faire cohabiter des codes MPI d'un coté et GPUs de l'autre.

Au début des coprocs, oui les codes utilisaient uniquement les GPUs et pas ou peu les CPUs. Ce n'est plus vrai depuis 2-3 ans, les gens ont bien compris que combiner les avantages des deux était très intéressant. Y a plein de solutions qui marchent, faut surtout que les gens se mettent d'accord sur comment exposer ça aux utilisateurs, en général par un graphe de tâches.

Pour MPI, la cohabitation avec GPU est venue très vite car les gens ont pris leur code CPU+MPI et ont remplacé CPU par GPU mais ils ont été obligés de garder MPI. Ca marchait mais ce n'était pas très optimal, notamment parce que le driver NVIDIA était tout pourri et imposait plein de copies mémoire inutiles pour aller du GPU au réseau. Ca a été corrigé depuis (et présenté comme une révolution alors que c'était surtout un bugfix) et maintenant GPU+MPI marche et est à peu près bien implémentable.

Donc maintenant y a combinaison des trois. En gros on prend le graphe de tâches utilisé pour combiner CPU et GPU, et on le répartit sur plusieurs machines, souvent à travers MPI. C'est encore beaucoup des travaux de recherche, mais ca avance bien.

Ouais LEO est plutot du genre OpenACC. Mais ça c'est si tu fais de l'offload. Tu peux aussi faire de l'OpenMP à l'intérieur du Phi.

Le nom "Xeon Phi" ne remplace pas Knights Corner mais plutot le nom officieux "MIC" (many integrated core). Knights Corner est le codename de la génération actuelle du Xeon Phi, comme Sandy-Bridge pour les Xeon ou Ivy-Bridge pour les Core i7.

OpenMP, ca marche bien quand tu as des machines de taille raisonnable. Dès que tu passes sur des machines avec plein de coeurs et d'effets NUMA, ca devient déjà plus difficile et les gens se mettent à faire des trucs à la main pour être surs que la mémoire et/ou les threads soient au bon endroit.
Sur Xeon Phi, c'est pas NUMA, mais y a beaucoup de coeurs, donc il va falloir que la parallélisation OpenMP scale bien, ce qui n'est pas toujours évidemment. Et comme expliqué plus haut, il y a les problèmes de mouvements de données entre hote et mémoire du Phi.

Tous les gros codes de simulation numérique ont été parallélisés. Et la plupart ont également été portés sur GPU quand c'était possible/intéressant. Ce qui reste à paralléliser, c'est plutot des codes moins conventionnels (j'ai vu des exemples pour de la cyrpto récemment par exemple). Mais ca ne concerne pas la grosse majorité des utilisateurs de centres de calcul.

Quant au portage sur Xeon Phi, evidemment c'est encore très peu fait. La grosse question est encore quel modèle de prog va être utilisé pour cette architecture. Intel fournit pas mal de modèles différents (offload par directive, offload manuel, MPI pur, …). Les gens vont peut-etre attendre un peu de voir les tendances avant d'investir du temps pour porter leur code. L'investissement devrait être moindre que sur GPU, mais ca ne sera pas complètement gratuit, faut pas rêver.

Qu'est-ce que tu entends par cohabitation avec les codes MPI ?

Sinon, on voit bien dans la dépêche que l'état fédéral américain aide bien ses constructeurs ;-)

Exactement comme le CEA et Bull chez nous.

Il est disponible gratuitement sur le stand Inria à Supercomputing aussi :)

lstopo ne montre pas les bus, mais les noeuds mémoire. Si ta machine est NUMA, tu verras plusieurs noeuds (NUMANode) avec chacun une certaine quantité de mémoire. Et en dessous de chaque boite représentant un noeud mémoire, tu as les coeurs/threads/caches proches de celui-ci.

La version actuelle se nomme Knights Corner est elle est gravée
en 22 nm pour un total de plus de 50 coeurs.

Il n'y a pas vraiment de version actuelle vu que le produit n'est pas encore commercialisé. La plupart des gens qui utilisent MIC depuis quelques temps (sous NDA) ont plutot accès à Knights Ferry (32 coeurs, pas très puissant…).

Knights Corner, c'est la première version qui sera commercialisée (22nm, plus de 50 coeurs, AVX2, …), vers la fin d'année normalement. On ne sait pas clairement si Discovery utilise l'un ou l'autre… probablement des preversion de KC vu les perfs potables.

Au passage, je ne suis pas sûr que git râle tout le temps quand on veut propager
un historique modifié, par exemple si on a fait un rebase interactif ou un de ces
trucs d'édition poussée de l'historique. J'ai le souvenir du contraire, mais
peut-être que ma mémoire me joue des tours. Ou alors git a amélioré cela ces
derniers temps."

Ta mémoire te joue des tours. Ca fait longtemps (i.e. au moins depuis que j'ai commencé à l'utiliser...) que Git interdit le non-fast-forward push par défaut. Et tous tes "trucs d'édition poussée de l'historique" (y compris un rebase interactif) sont concernés.

C'est dans quel domaine de recherche ? Chez nous, en informatique, s'il faut payer pour publier (en dehors des extras couleurs/pages), on passe notre chemin (voire on marque comme spam...).

Ton labo a payé 1000€ pour la publication de ton article ??? C'était pour des pages supplémentaires ou pour l'article lui-même ?

git bisect n'est vraiment pas un bon exemple quand on parle de maitriser les rouages de git, c'est vraiment facile d'en comprendre la "théorie" et d'en maitriser la pratique...

Comme ca fait 2 fois d'affilée que les USA n'ont qu'un seul des 5 premiers du classement, ca fait tâche. Du coup, on commence à entendre des grands chercheurs américains dire que Linpack et le Top500 ne sont pas une bonne mesure de la vraie performance (voire de la valeur) des machines. C'est pas nouveau, mais on ne l'entendait pas trop quand Jaguar était premier :)

Blue Waters n'a pas été annulé, c'est le contrat IBM pour Blue Waters qui l'a été. Il a été annoncé hier que Blue Waters serait finalement une Cray, un peu comme le futur Titan (l'upgrade de Jaguar avec le réseau Gemini, des Opterons 16 coeurs et un peu de GPUs).

man rgrep

A chaque fois que j'ai regardé cfengine depuis 10 ans, j'ai abandonné rapidement parce que la syntaxe des fichiers de config était trop compliquée. AU final j'utilise puppet pour mes besoins (propagation de fichiers/templates assez simples).

Exactement, et il n'a pas non plus moyen de savoir si allouer une huge page est une bonne idée ici ou non, donc il ne le fait pas car gachi. Par contre, si on lui demande 1Go, là il sait que c'est surement une bonne idée de prendre une huge-page.

Euh, j'ai jamais joué sur les mots "système", ou "appel système" ou pas moi hein, j'ai juste dit "... dès qu'un processus demande une allocation d'un octet..." au départ. Fallait juste pas que vous lisiez "appel système" là dedans. Si vous interprétez tout n'importe comment, faut pas vous étonner de lancer un troll...

C'est surtout que ça fait des années qu'utiliser des hugepage est une galère monstrueuse et que donc les gens restent sur les petites…

Une galère sous Linux oui. Mais d'autres systèmes ont une gestion intéressante depuis longtemps (IRIX iirc), et de tels systèmes ont été utilisés par les mecs qui utilisent des gros codes parallèles optimisés pour ce genre de problème.

Je sais pu où en est cette feature, mais c'était uniquement pour le code et les données statiques en tout cas, pas pour tout le reste que le noyau alloue dynamiquement.