Ma femme (dont le portable est en testing/buster) est passée à KDE il y a 1 an après une overdose de régressions dans Gnome, pas de problème à signaler sous KDE depuis.
J'ai changé depuis Gnome 3.2 en fait. Mais quelques postes autour de moi étaient restés en Gnome 3 parce que je les utilisait peu personnellement, parce que leurs utilisateurs (moins intensifs que moi) avaient autre chose à faire que de s'habituer à un autre environnement, et parce que je gardais espoir que les développeurs reviendraient à la raison au lieu de décider qu'il faudrait maintenant appuyer sur ctrl pour ouvrir une nouvelle instance. Mais ces arguments sont devenus insuffisants au bout de plusieurs années.
A propos du temps dépensé à faire des efforts ou migrer, le problème est qu'on ne sait jamais à l'avance combien d'effort il faudra pour migrer, et on ne sait pas trop non plus si ça marchera bien sur le long terme. Ma migration Gnome 3.2 -> XFCE avait été facile car ça ressemblait au Gnome 2 de quelques moins avant. Mais après s'être habitué à Gnome 3 pendant des années, migrer vers KDE par exemple demande un bon temps d'adaptation.
On a fait des efforts pendant des années mais là ce n'est plus possible, on est arreté d'utiliser Gnome à partir du 3.30. Entre les fonctionnalités qui disparaissent, celles qui restent uniquement possibles avec des extensions plus ou moins solides (icones sur le bureau, ouvrir une nouvelle instance d'un programme avec le click gauche, etc), les mises à jour qui ont du mal à conserver la configuration, Nautilus qui rame sans raison (même en vidant le home de l'utilisateur pour nettoyer sa config), Gnome était devenu inutilisable depuis bien trop longtemps.
J'ai moi aussi une IPv4 partagée, et j'ai juste bougé mes serveurs sur des ports dans la bonne plage, tout roule.
Je serais bien passé en IPv6 sauf que la Freebox ne fait pas du tout de firewall en IPv6. Pour mes ordinateurs, je m'en fiche, je sais configurer leur firewall. Mais pour le reste sur lequel on a presqu'aucun moyen de configurer, c'est un peu risqué je trouve. Même s'il est peu probable que quelqu'un devine leur IP IPv6 publique, je n'ai pas très envie de les laisser accessibles sur Internet. Quand on voit toutes les failles dans les objets connectés, sans aucun correctif de sécurité, ca donne pas très envie…
Ca serait quand même plus simple que la Freebox centralise le firewall plutot que nous laisser espérer pouvoir le configurer sur chacun des terminaux derrière…
NUMA est orthogonal à multi-socket. Il y a 10 ans, on avait plusieurs processeurs par noeud NUMA sur Itanium. Maintenant c'est le contraire, les processeurs sont NUMA en interne, sans même être dans une machine multi-processeur. Par exemple, sur un bi-processeur Xeon E5v3, il peut y avoir 4 noeuds NUMA, 2 dans chaque processeur: https://pbs.twimg.com/media/Ce7r-DoWQAUlE0l.jpg:large
Les processeurs pour serveur des autres constructeurs qu'Intel suivent la même tendance.
une meilleure répartition des processus permet d'avoir plus de bande passante mémoire et donc de meilleures performances.
Ca dépend des applications… Pour les applications qui font du gros streaming mémoire, peut-être. Pour les applications qui utilisent un jeu de données relativement petit (de l'ordre de quelques megaoctets ou dizaines de mégaoctets, de nos jours), ca tient dans le cache, elles s'en fichent du débit mémoire. Et si on garde les processus proches au lieu de les répartir, le partage mémoire entre eux sera plus rapide.
C'est le genre d'info que l'ordonnanceur ignore quand il répartit les processus. D'où la nécessité de binder les tâches à la main depuis l'espace utilisateur quand on fait du HPC.
Et pour répondre aux questions trouvées dans les autres commentaires: c'est basé sur GIT et GPG. Donc on a une copie locale en permanence, une gestion automatique des révisions, un partage basé sur les commandes git, etc. Et c'est en ligne de commande mais il y a des plugins pour les navigateurs.
C'est uniquement détection du support AVX-512 et la sauvegarde des registres concernées au changement de contexte qui a été ajouté.
Le noyau lui-même ne se sert pas de ces instructions. En général, il s'en sert assez peu, à part peut-être pour les copies-mémoire (même pas sûr vu que le cache regroupe les accès par dessus) et éventuellement de nouvelles fonctions implémentées en hard (CRC, crypto, etc).
C'est plutot faux. Quand on achète des calculateurs, on demande aux vendeurs de faire tourner nos benchs sur les architectures qu'ils vont nous vendre, pas sur celles qui seront disponibles plus tard lors de la livraison (environ 3 mois plus tard en général).
A part pour des très gros coup où les constructeurs donnent des prototypes (genre les Xeon E5 Ivy Bridge de Tianhe-2) où faire des benchs préalables peut-etre difficile (à confirmer), le délai commande/fabrication ne joue pas.
Ca fait plusieurs années que AMD n'est pas au mieux face à Intel, depuis la sortie des Nehalems en 2009, en gros. Les machines du Top500 actuel ont été commandées très longtemps après.
Je trouve pas les chiffres exacts en ligne mais Jack Dongarra a présenté cette semaine un slide expliquant que la durée est très variable selon le supercalculateur. Pour le numéro 1 actuel Tianhe-2, c'est 5 heures. Titan (numéro 2) est plutot vers 1 heure si je me souviens bien. Sequoia (n°3) 23h. Et certains prennent plus de 24 heures.
C'est une grosse cuisine tout ce truc de tuning du Linpack. A la base, la durée n'est pas le facteur critique. On cherche d'abord une bonne taille de problème qui permet de bien remplir pile-poil la mémoire des noeuds et/ou des accélérateurs, comme ça y a plus de calcul et moins de transfert de données à faire, donc plus de flop/s. Mais si ca donne un run qui prend 3 mois, ca peut pas aller. D'une part pour des histoires de pannes (sur un BlueGene c'est pas très dur d'avoir 1 million de coeurs qui marchent pendant 24h, sur d'autres machines ca dépend…), mais aussi parce que les centres de calcul ont pas que ça à faire que gaspiller un mois d'investissement et d'électricité pour un Linpack qui ne sert à rien dans la vraie vie :)
Oui c'est clair que si on avait les prix, ca donnerait un éclairage différent. Il y a eu souvent dans le passé des supercalculateurs dont l'architecture a été completement modifiée suite à un "cadeau" d'un constructeur.
Après, en pratique, c'est plutot le cout de fonctionnement qui compte pour les centres de calcul, plus que le cout d'achat. Et ça, ça s'estime en regardant la conso énergétique dans la liste (je n'arrive plus à retrouver si celle-là inclut la conso pour le refroidissement ou pas).
D'ailleurs, si on compare SuperMUC (numéro 10, 150000 coeurs Xeon E5) et Garnet (numéro 25, 150000 coeurs Opteron, ou les numéros 26 et 28 juste après), on trouve un facteur 2 de différence de perf théorique (Rmax) et un facteur 4 sur Linpack (Rpeak). Tout n'est surement pas lié au processeur, le réseau de Cray joue surement aussi, mais quand même, ca fait une sacrée différence…
1) Les opterons ont plus de coeurs, mais les unités flottantes sont partagées par paire de coeurs (un seul peut faire de l'AVX à la fois), donc au final les processeurs à 16 coeurs d'AMD ne peuvent faire que 8 AVX à la fois. Alors que les Xeon E5 viennent de passer à 12 coeurs, ils font 12 AVX en même temps.
2) Même si les codes sont parallélisés au maximum, la parallélisation a toujours un surcout. Les utilisateurs prefereront très souvent moins de coeurs si ces coeurs sont beaucoup plus rapides, car les codes les exploiteront souvent plus facilement.
3) Les benchs HPC des opterons sont à peu près aussi mauvais que les benchs grands publics, à cause des flottants, mais aussi à cause de la memoire (les caches sont petits et lents). A moins d'avoir un code très parallèles et peu vectorisable, ou de vouloir plein de coeurs pour frimer en soirée, y a très peu de personnes qui ont intérêt à acheter du AMD en HPC malheureusement.
Non, il n'y a pas vraiment d'évolution sur la date d'atteinte de l'exaflop. Dès que le petaflop a été passé et qu'on a commencé à estimer le date de l'exaflop, c'était déjà une grosse fourchette 2018-2020 voire 2018-2025.
Les architectures NUMA, où chaque processeur a un contrôleur
mémoire dédié, nécessitent une révision de l'ordonnanceur.
En effet, l'ordonnanceur doit tenir compte de la topologie
du CPU pour placer un processus sur le cœur le plus proche
de sa mémoire. L'ordonnanceur actuel est trop naïf pour ces
architectures, ce qui provoque des pertes de performances.
Le problème est justement qu'il ne faut que ce soit uniquement l'ordonnanceur qui gère ça. Si les données sont bien réparties en mémoire, il arrivera peut-etre à répartir les processus près de leurs données tout en équilibrant bien la charge parmi les processeurs. Mais dans la plupart des cas, mettre les processus près de leurs données va imposer un déséquilibre de charge de calcul.
Et on se pose alors la question de migrer certaines données vers un autre noeud NUMA. En gros il faut répartir les données et les calcul en même temps, pas l'un puis l'autre.
Au final, il faut que l'ordonnanceur et la gestion mémoire se mettent d'accord sur une de ces stratégies :
1) est-ce qu'on migre les processus près des données (pas très cher, mais peut déséquilibrer la charge de calcul)
2) est-ce qu'on migre les données près des processus (cher, équilibre mieux la charge de calcul)
3) ne rien faire, équilibrer la charge et avoir éventuellement des processus qui utilise des données loin d'eux, et donc plus lentement.
Comparer ces trois approches est très difficile car ça impose de connaître les schémas d'accès mémoire des processus pour évaluer les différents surcoûts ci-dessus.
L'autre coquille, c'est que les architectures NUMA n'ont pas forcément un controleur par processeur. Les Opteron et Intel (depuis Nehalem) ont un controleur mémoire intégré. Mais avant, quand le controleur n'était pas intégré, il pouvait y avoir plusieurs processeurs autour de chacun des controleurs. IBM, SGI et Bull notamment, ont longtemps fait des grosses machines NUMA comme ça, avec par exemple 2 ou 4 Itanium ou Xeon pre-Nehalem autour de chaque controleur.
Au contraire, vu que les dernières cartes graphiques professionnelles
de quelques centaines d'euros atteignent déjà le teraflops (en double
précision), il parait plus intéressant pour un tel industriel d'avoir
son propre calculateur.
Pour quelques centaines d'euros, t'as des cartes de gamers, pas des cartes Pro. Pour le HPC, c'est bof, par exemple parce que la mémoire n'est pas ECC. On prend des cartes pros ou spécialisées en HPC, mais ca coute beaucoup plus chers.
En double-précision, il n'y a que les toutes dernières cartes qui s'approchent du teraflop/s (celles annoncés à SC12 en gros). Elles vont couter plus de 2000€ que ce soit chez Intel, NVIDIA ou AMD. Et tout ça, c'est du teraflop/s théorique. La plupart des vrais applis n'en exploitent qu'une toute petite part…
Pourrais-tu nous dire si Météo France se sert de machines du top500 pour
établir ses prévisions météo.
Meteofrance utilise a priori actuellement un NEC SX9 acheté en 2009 dont la puissance est de l'ordre de 50 Tera si je me souviens bien. Mais il n'a pas l'air d'avoir jamais été dans le top500.
Les délais ca s'anticipe. Les industriels savent bien à l'avance quand ils vont besoin de ressources de calcul.
L'avantage des gros calculateurs, c'est un peu comme le cloud, tu factorises plein de couts par rapport à avoir plein de petits calculateurs partout. Un industriel qui a besoin d'un teraflop/s 10 semaines par an, aucune utilité d'avoir chez lui un calculateur. Seuls les gros (comme Total ou météofrance chez nous) qui font des calculs tout le temps peuvent justifier un tel investissement.
[^] # Re: Des utilisateurs de KDE avec des retours ? :)
Posté par Brice Goglin . En réponse à la dépêche Debian 10 Buster : une distribution qui a du chien. Évalué à 9.
Ma femme (dont le portable est en testing/buster) est passée à KDE il y a 1 an après une overdose de régressions dans Gnome, pas de problème à signaler sous KDE depuis.
[^] # Re: ca suffit
Posté par Brice Goglin . En réponse à la dépêche Parution de GNOME 3.30. Évalué à 2.
J'ai changé depuis Gnome 3.2 en fait. Mais quelques postes autour de moi étaient restés en Gnome 3 parce que je les utilisait peu personnellement, parce que leurs utilisateurs (moins intensifs que moi) avaient autre chose à faire que de s'habituer à un autre environnement, et parce que je gardais espoir que les développeurs reviendraient à la raison au lieu de décider qu'il faudrait maintenant appuyer sur ctrl pour ouvrir une nouvelle instance. Mais ces arguments sont devenus insuffisants au bout de plusieurs années.
A propos du temps dépensé à faire des efforts ou migrer, le problème est qu'on ne sait jamais à l'avance combien d'effort il faudra pour migrer, et on ne sait pas trop non plus si ça marchera bien sur le long terme. Ma migration Gnome 3.2 -> XFCE avait été facile car ça ressemblait au Gnome 2 de quelques moins avant. Mais après s'être habitué à Gnome 3 pendant des années, migrer vers KDE par exemple demande un bon temps d'adaptation.
# ca suffit
Posté par Brice Goglin . En réponse à la dépêche Parution de GNOME 3.30. Évalué à -4.
On a fait des efforts pendant des années mais là ce n'est plus possible, on est arreté d'utiliser Gnome à partir du 3.30. Entre les fonctionnalités qui disparaissent, celles qui restent uniquement possibles avec des extensions plus ou moins solides (icones sur le bureau, ouvrir une nouvelle instance d'un programme avec le click gauche, etc), les mises à jour qui ont du mal à conserver la configuration, Nautilus qui rame sans raison (même en vidant le home de l'utilisateur pour nettoyer sa config), Gnome était devenu inutilisable depuis bien trop longtemps.
# pas de firewall IPv6 sur la Freebox
Posté par Brice Goglin . En réponse à la dépêche La fin des IPv4 est très proche ! Les ennuis aussi…. Évalué à 9.
J'ai moi aussi une IPv4 partagée, et j'ai juste bougé mes serveurs sur des ports dans la bonne plage, tout roule.
Je serais bien passé en IPv6 sauf que la Freebox ne fait pas du tout de firewall en IPv6. Pour mes ordinateurs, je m'en fiche, je sais configurer leur firewall. Mais pour le reste sur lequel on a presqu'aucun moyen de configurer, c'est un peu risqué je trouve. Même s'il est peu probable que quelqu'un devine leur IP IPv6 publique, je n'ai pas très envie de les laisser accessibles sur Internet. Quand on voit toutes les failles dans les objets connectés, sans aucun correctif de sécurité, ca donne pas très envie…
Ca serait quand même plus simple que la Freebox centralise le firewall plutot que nous laisser espérer pouvoir le configurer sur chacun des terminaux derrière…
[^] # Re: La fin d’Intel
Posté par Brice Goglin . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 6.
les Xeon Phi dont Intel a annoncé l'abandon du prochain en novembre ?
[^] # Re: fabricants
Posté par Brice Goglin . En réponse à la dépêche Le Top 500 des supercalculateurs de juin 2016. Évalué à 6.
Le #11 Pangea de Total ne compte pas ? C'est un SGI et il est en France…
# NUMA != multi-socket
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau Linux 4.6. Évalué à 10.
NUMA est orthogonal à multi-socket. Il y a 10 ans, on avait plusieurs processeurs par noeud NUMA sur Itanium. Maintenant c'est le contraire, les processeurs sont NUMA en interne, sans même être dans une machine multi-processeur. Par exemple, sur un bi-processeur Xeon E5v3, il peut y avoir 4 noeuds NUMA, 2 dans chaque processeur:
https://pbs.twimg.com/media/Ce7r-DoWQAUlE0l.jpg:large
Les processeurs pour serveur des autres constructeurs qu'Intel suivent la même tendance.
Ca dépend des applications… Pour les applications qui font du gros streaming mémoire, peut-être. Pour les applications qui utilisent un jeu de données relativement petit (de l'ordre de quelques megaoctets ou dizaines de mégaoctets, de nos jours), ca tient dans le cache, elles s'en fichent du débit mémoire. Et si on garde les processus proches au lieu de les répartir, le partage mémoire entre eux sera plus rapide.
C'est le genre d'info que l'ordonnanceur ignore quand il répartit les processus. D'où la nécessité de binder les tâches à la main depuis l'espace utilisateur quand on fait du HPC.
[^] # Re: histoire de ne pas me faire troller à coup de terrorisme intellectuel...
Posté par Brice Goglin . En réponse à la dépêche Passbolt, un nouveau gestionnaire de mots de passe pour les équipes. Évalué à 2.
marche très bien
Et pour répondre aux questions trouvées dans les autres commentaires: c'est basé sur GIT et GPG. Donc on a une copie locale en permanence, une gestion automatique des révisions, un partage basé sur les commandes git, etc. Et c'est en ligne de commande mais il y a des plugins pour les navigateurs.
[^] # Re: histoire de ne pas me faire troller à coup de terrorisme intellectuel...
Posté par Brice Goglin . En réponse à la dépêche Passbolt, un nouveau gestionnaire de mots de passe pour les équipes. Évalué à 4.
https://www.passwordstore.org/ marche très aussi (et il fait la gestion en équipe même si je n'ai pas testé cette fonctionnalité).
apt-get install pass
# tox est amour
Posté par Brice Goglin . En réponse à la dépêche Programme de la PyConFR 2015. Évalué à 3.
Pas tant que ça d'après le talk juste après…
[^] # Re: distribution linux
Posté par Brice Goglin . En réponse à la dépêche Le Top 500 de juin 2014. Évalué à 6.
Si on exclut quelques trucs bizarres (BlueGene et Cray notamment), une très grande majorité tourne en distro RPM, notamment du CentOS, RHEL et SUSE.
[^] # Re: AVX-512 ?
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau Linux 3.15. Évalué à 6.
C'est uniquement détection du support AVX-512 et la sauvegarde des registres concernées au changement de contexte qui a été ajouté.
Le noyau lui-même ne se sert pas de ces instructions. En général, il s'en sert assez peu, à part peut-être pour les copies-mémoire (même pas sûr vu que le cache regroupe les accès par dessus) et éventuellement de nouvelles fonctions implémentées en hard (CRC, crypto, etc).
[^] # Re: Kernel stack
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau Linux 3.15. Évalué à 4.
Les processeurs AMD opterons, au moins la génération Bulldozer, ont un L1d de 16ko par coeur.
[^] # Re: À propos d'opterons
Posté par Brice Goglin . En réponse à la dépêche Le Top 500 de novembre 2013. Évalué à 3.
C'est plutot faux. Quand on achète des calculateurs, on demande aux vendeurs de faire tourner nos benchs sur les architectures qu'ils vont nous vendre, pas sur celles qui seront disponibles plus tard lors de la livraison (environ 3 mois plus tard en général).
A part pour des très gros coup où les constructeurs donnent des prototypes (genre les Xeon E5 Ivy Bridge de Tianhe-2) où faire des benchs préalables peut-etre difficile (à confirmer), le délai commande/fabrication ne joue pas.
Ca fait plusieurs années que AMD n'est pas au mieux face à Intel, depuis la sortie des Nehalems en 2009, en gros. Les machines du Top500 actuel ont été commandées très longtemps après.
[^] # Re: Et nos ordinateurs personnels ?
Posté par Brice Goglin . En réponse à la dépêche Le Top 500 de novembre 2013. Évalué à 5.
Je trouve pas les chiffres exacts en ligne mais Jack Dongarra a présenté cette semaine un slide expliquant que la durée est très variable selon le supercalculateur. Pour le numéro 1 actuel Tianhe-2, c'est 5 heures. Titan (numéro 2) est plutot vers 1 heure si je me souviens bien. Sequoia (n°3) 23h. Et certains prennent plus de 24 heures.
C'est une grosse cuisine tout ce truc de tuning du Linpack. A la base, la durée n'est pas le facteur critique. On cherche d'abord une bonne taille de problème qui permet de bien remplir pile-poil la mémoire des noeuds et/ou des accélérateurs, comme ça y a plus de calcul et moins de transfert de données à faire, donc plus de flop/s. Mais si ca donne un run qui prend 3 mois, ca peut pas aller. D'une part pour des histoires de pannes (sur un BlueGene c'est pas très dur d'avoir 1 million de coeurs qui marchent pendant 24h, sur d'autres machines ca dépend…), mais aussi parce que les centres de calcul ont pas que ça à faire que gaspiller un mois d'investissement et d'électricité pour un Linpack qui ne sert à rien dans la vraie vie :)
[^] # Re: À propos d'opterons
Posté par Brice Goglin . En réponse à la dépêche Le Top 500 de novembre 2013. Évalué à 4.
Les opterons ont toujours plus de coeurs (16 depuis longtemps contre 12 depuis récemment).
[^] # Re: À propos d'opterons
Posté par Brice Goglin . En réponse à la dépêche Le Top 500 de novembre 2013. Évalué à 2.
Oui c'est clair que si on avait les prix, ca donnerait un éclairage différent. Il y a eu souvent dans le passé des supercalculateurs dont l'architecture a été completement modifiée suite à un "cadeau" d'un constructeur.
Après, en pratique, c'est plutot le cout de fonctionnement qui compte pour les centres de calcul, plus que le cout d'achat. Et ça, ça s'estime en regardant la conso énergétique dans la liste (je n'arrive plus à retrouver si celle-là inclut la conso pour le refroidissement ou pas).
[^] # Re: À propos d'opterons
Posté par Brice Goglin . En réponse à la dépêche Le Top 500 de novembre 2013. Évalué à 3.
D'ailleurs, si on compare SuperMUC (numéro 10, 150000 coeurs Xeon E5) et Garnet (numéro 25, 150000 coeurs Opteron, ou les numéros 26 et 28 juste après), on trouve un facteur 2 de différence de perf théorique (Rmax) et un facteur 4 sur Linpack (Rpeak). Tout n'est surement pas lié au processeur, le réseau de Cray joue surement aussi, mais quand même, ca fait une sacrée différence…
[^] # Re: À propos d'opterons
Posté par Brice Goglin . En réponse à la dépêche Le Top 500 de novembre 2013. Évalué à 8.
Ouh la, non.
1) Les opterons ont plus de coeurs, mais les unités flottantes sont partagées par paire de coeurs (un seul peut faire de l'AVX à la fois), donc au final les processeurs à 16 coeurs d'AMD ne peuvent faire que 8 AVX à la fois. Alors que les Xeon E5 viennent de passer à 12 coeurs, ils font 12 AVX en même temps.
2) Même si les codes sont parallélisés au maximum, la parallélisation a toujours un surcout. Les utilisateurs prefereront très souvent moins de coeurs si ces coeurs sont beaucoup plus rapides, car les codes les exploiteront souvent plus facilement.
3) Les benchs HPC des opterons sont à peu près aussi mauvais que les benchs grands publics, à cause des flottants, mais aussi à cause de la memoire (les caches sont petits et lents). A moins d'avoir un code très parallèles et peu vectorisable, ou de vouloir plein de coeurs pour frimer en soirée, y a très peu de personnes qui ont intérêt à acheter du AMD en HPC malheureusement.
# 2018 ou 2020 ?
Posté par Brice Goglin . En réponse à la dépêche Le Top 500 de novembre 2013. Évalué à 4.
Non, il n'y a pas vraiment d'évolution sur la date d'atteinte de l'exaflop. Dès que le petaflop a été passé et qu'on a commencé à estimer le date de l'exaflop, c'était déjà une grosse fourchette 2018-2020 voire 2018-2025.
[^] # Re: ordonnancement NUMA
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau Linux 3.8. Évalué à 1.
Merci
# ordonnancement NUMA
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau Linux 3.8. Évalué à 5.
Le problème est justement qu'il ne faut que ce soit uniquement l'ordonnanceur qui gère ça. Si les données sont bien réparties en mémoire, il arrivera peut-etre à répartir les processus près de leurs données tout en équilibrant bien la charge parmi les processeurs. Mais dans la plupart des cas, mettre les processus près de leurs données va imposer un déséquilibre de charge de calcul.
Et on se pose alors la question de migrer certaines données vers un autre noeud NUMA. En gros il faut répartir les données et les calcul en même temps, pas l'un puis l'autre.
Au final, il faut que l'ordonnanceur et la gestion mémoire se mettent d'accord sur une de ces stratégies :
1) est-ce qu'on migre les processus près des données (pas très cher, mais peut déséquilibrer la charge de calcul)
2) est-ce qu'on migre les données près des processus (cher, équilibre mieux la charge de calcul)
3) ne rien faire, équilibrer la charge et avoir éventuellement des processus qui utilise des données loin d'eux, et donc plus lentement.
Comparer ces trois approches est très difficile car ça impose de connaître les schémas d'accès mémoire des processus pour évaluer les différents surcoûts ci-dessus.
[^] # Re: Coquille
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau Linux 3.8. Évalué à 3.
L'autre coquille, c'est que les architectures NUMA n'ont pas forcément un controleur par processeur. Les Opteron et Intel (depuis Nehalem) ont un controleur mémoire intégré. Mais avant, quand le controleur n'était pas intégré, il pouvait y avoir plusieurs processeurs autour de chacun des controleurs. IBM, SGI et Bull notamment, ont longtemps fait des grosses machines NUMA comme ça, avec par exemple 2 ou 4 Itanium ou Xeon pre-Nehalem autour de chaque controleur.
[^] # Re: Utilité ?
Posté par Brice Goglin . En réponse à la dépêche Le Top 500 de novembre 2012. Évalué à 4.
Pour quelques centaines d'euros, t'as des cartes de gamers, pas des cartes Pro. Pour le HPC, c'est bof, par exemple parce que la mémoire n'est pas ECC. On prend des cartes pros ou spécialisées en HPC, mais ca coute beaucoup plus chers.
En double-précision, il n'y a que les toutes dernières cartes qui s'approchent du teraflop/s (celles annoncés à SC12 en gros). Elles vont couter plus de 2000€ que ce soit chez Intel, NVIDIA ou AMD. Et tout ça, c'est du teraflop/s théorique. La plupart des vrais applis n'en exploitent qu'une toute petite part…
Meteofrance utilise a priori actuellement un NEC SX9 acheté en 2009 dont la puissance est de l'ordre de 50 Tera si je me souviens bien. Mais il n'a pas l'air d'avoir jamais été dans le top500.
Brice
[^] # Re: Utilité ?
Posté par Brice Goglin . En réponse à la dépêche Le Top 500 de novembre 2012. Évalué à 3.
Les délais ca s'anticipe. Les industriels savent bien à l'avance quand ils vont besoin de ressources de calcul.
L'avantage des gros calculateurs, c'est un peu comme le cloud, tu factorises plein de couts par rapport à avoir plein de petits calculateurs partout. Un industriel qui a besoin d'un teraflop/s 10 semaines par an, aucune utilité d'avoir chez lui un calculateur. Seuls les gros (comme Total ou météofrance chez nous) qui font des calculs tout le temps peuvent justifier un tel investissement.