lasher a écrit 2732 commentaires

Juste une remarque sur l'Itanium : il faut bien comprendre que la première génération était tout simplement ratée : Intel/HP étaient très en retard sur les délais, et ont dû sortir « un truc qui marche ». Bref, quand le Merced est sorti, bien sûr ça marchait, mais franchement, c'était plus un prototype qu'autre chose.

Lorsque l'Itanium 2 est sorti, il s'agissait de ce que la première génération aurait dû être, mais le mal était déjà fait. De plus, la chaîne de compilation d'Intel a mis deux générations à correctement utiliser les registres rotatifs pour effectuer un bon software pipelining.

Concernant ton exemple de la multiplication de matrices, j'ai envie de dire que c'est un « faux bon exemple » : le compilateur d'Intel (et probablement gcc, mais je n'ai pas vérifié) sait désormais appeler les routines BLAS qui vont bien une fois qu'il reconnaît un « idiome ».

Par contre une particularité d'icc pour IA64 était que, si on pouvait appeler des intrinsics, il était absolument impossible d'inliner de l'assembleur (ça provoquait une erreur de compilation).

Enfin, avec les versions 8 et ultérieures, icc avait des performances trois fois meilleures que gcc (je parle de la période 2005-2010). C'est normal cependant : un Itanium 2 ça coûte cher, c'est rare, et ce n'est utile que pour le calcul scientifique (les performances pour du calcul entier sont quand même assez minables). Forcément, optimiser gcc-IA64 n'était pas la priorité pour GCC…

Si, totalement. Bon, j'ai pas mal trituré mes codes, mais celui-là, je suis allé un peu vite. Y a-t-il un modérateur qui pourrait changer le code ? :)

La seule partie « CISC » du x86 est le couple fetch-decode du front-end. Pour les processeurs jusqu'à la micro-architecture Nehalem (6 pour Sandy Bridge et aussi sans doute Ivy Bridge, mais je n'ai pas suivi), le décodeur a quatre ports (considère ça comme des entrées) : le premier décode toutes les instructions CISC de 1 octet ou plus; les trois autres s'occupent d'instructions de 1 octet très exactement. Une fois le décodage effectué, tout le reste est bel et bien résolu comme pour une machine RISC classique. Il y a longtemps (plus de 10 ans), mon prof d'architecture appelait ça du « CRISC » : front-end CISC (étages IF et ID du pipeline), mais back-end RISC (tous les autres étages). Pour un processeur de type Pentium III ou Pentium 4, ça veut dire qu'environ 17% du temps est passé dans un module « CISC » (dans mes souvenirs le PIII avait 12 étages), et environ 6% pour le P4. En pratique comme les core 2 et suivants sont des évolutions du PIII, on peut toujours considérer que ~16-17% est passé dans le front-end.

Dire que le coeur x86 a derrière un RISC bof, ça n'a pas grand sens:
1) déjà c'est un jeu d'instruction qui est visible uniquement en interne: le compilateur n'y a pas accès. […]

C'est vrai.

Ce qui pose des contraintes par exemple pour l'accès aux registres: le compilateur peut-être obligé d'écrire un registre x86 en mémoire pour faire de la place alors que le CPU a bien assez de registres physiquement présent, mais ils sont cachés et inaccessible directement..

Je suis d'accord pour x86 non 64 bits (où on n'avait en gros que 15 registres adressables). À partir du moment où tu peux utiliser rax, rbx, …, r15, et en plus de cela tu peux aussi utiliser les xmm0, …, xmm15 comme s'il s'agissait de registres scalaires, tu as bien 32 registres. Je n'ai pas les références en tête, mais en gros, il a été montré qu'avec les heuristiques actuelles pour l'allocation de registres et l'ordonnancement d'instructions, sauf à avoir des codes vraiment très réguliers (donc typiquement du HPC ;-)), on n'exploitait pas correctement les registres et les solutions d'allocation sont souvent sub-optimales (ce qui est « normal » en soit : l'ordonnancement des instructions et l'allocation des registres sont deux problèmes NP-complets).

2) les micro instructions suivent-elle vraiment les principes du RISC […]

Oui. Là-dessus il n'y a absolument pas de doute possible.

Il faut bien comprendre qu'avant l'introduction de RISC, la seule façon (à ma connaissance) de garantir une instruction par cycle était à travers les processeurs vectoriels, tels que le (mythique) Cray-I. C'est-à-dire : on garantit que deux longs vecteurs de données (pour le Cray-I, il faut compter 2 vecteurs de 32 mots maximum chacun) sont chargés en mémoire. Ensuite on applique la même opération (+, -, etc.) sur deux mots (un de chaque vecteur), et on stocke le résultat quelque part pour chaque cycle. Bref, on garantit que les opérandes seront disponibles cycle après cycle pendant n cycles (32 par ex.). Comme on pouvait « chaîner » certaines opérations (multiplications puis additions par exemple), on pouvait gagner énormément de temps au final. Ici il s'agissait plus d'une sorte de « pipeline mémoire » que d'un pipeline d'instruction au final. Un système de masquage de bits permettait aussi de gérer les branchements conditionnels tant qu'au final une opération vectorielle allait s'effectuer.

Ce qu'a apporté le RISC comparé aux processeurs vectoriels, c'est la possibilité d'effectuer des instructions différentes cycle après cycle, et garantir qu'en moyenne, on aura bien un débit proche de une instruction par cycle (certes, grâce à un programmeur très compétent, ou un compilateur très intelligent).

Enfin, je vais donner un argument d'autorité :

les micro instructions suivent-elle vraiment les principes du RISC […] peut-être, peut-être pas, vous avez la doc d'Intel vous?

J'ai the next best thing : j'ai bossé (et je continue de bosser) avec Intel. Je ne suis pas un employé par contre. J'ai passé quelques années à faire des micro-benchmarks pour caractériser les architectures Intel (Core 2, Nehalem en particulier), et ça passait entre autres par des trucs du genre « faire des programmes "RISC" en x86 », « utiliser des instructions exotiques que personne n'utilise », « utiliser des instructions que le compilateur utilise souvent (genre lea) », etc.

Ensuite, la page wikipedia (langue anglaise) n'est pas sourcée lorsqu'elle affirme que derrière le front-end, on a un moteur RISC. AnandTech est d'accord avec moi et Wikipedia cependant, et d'un point de vue très pratique, faire un pipeline qui n'accepte pas des mots de taille identique est quelque chose d'assez compliqué à réaliser (et les bénéfices en termes de performance peuvent être éclipsés par l'énergie nécessaire pour mettre en œuvre ce genre de solution).

Ce n'est pas pour dire qu'il n'y a pas des optimisations possibles pour la partie CISC du processeur. Si tu vas sur le site d'Agner, tu verras qu'il décrit plutôt bien la façon dont les pipelines des différents processeurs sont réalisés. Il existe des mécanismes de « macro-fusion » qui permettent de « factoriser » certains traitements pour accélérer le décodage des instructions, etc.

Déjà, tu as raison.

Lorsque j'utilisais Mac OS X (il y a longtemps, certes), les binaires « de base » étaient certes la version BSD (et donc tu as raison, j'ai fait une généralisation grossière), mais les autres outils (tar, make, etc.) étaient clairement GNU.

Pour moi c'était pas tant un troll, que d'essayer de pousser la logique et comprendre jusqu'où cette feature est utile. Mes questions, aussi enquiquinantes soient-elles, sont de vraies questions, et ne sont pas là pour faire de la provoc' pure et dure. :-)

Et bien, il est là le problème. On part d'une solution à base d'un template et on continue en rajoutant un soupçon de meta-programming pour obtenir les mêmes résultats.

Oui, mais une fois que tu as codé ton truc avec des milliards de templates affreux, tu as sans doute une interface simple à utiliser (du genre de ce que je proposais). Et c'est écrit une fois pour toutes, et fonctionnera pour toutes les classes qui ont un comportement « prévisible » (i.e. qui implémentent les opérateurs de comparaison, affectation, etc., selon un mode de fonctionnement similaire aux opérations utilisables sur les types primitifs).

Note que je ne nie pas que le fait que ce soit intégré au langage soit une excellente chose; juste que à partir du moment où tu voudras utiliser des objets plus complexes, je ne suis pas certain que tu ne finiras pas, même en Ada, avec une solution usine à gaz potentiellement plus compliquée à mettre en œuvre que ma bête solution en C++.

Pour info, je me considère comme « moyen » en C++ pour le langage lui-même, et j'ai mis moins d'une heure¹ pour créer un template de classe qui vérifie dynamiquement les bornes; je sais comment faire la même chose statiquement en théorie, mais comme je pratique peu la méta-programmation, il est évident que ça me prendrait beaucoup plus de temps à correctement programmer. Ceci étant dit, programmer la fonctionnalité des plages dans un compilateur Ada n'est pas nécessairement moins compliquée, et dans les deux cas, l'utilisateur final n'a pas à regarder l'implémentation. ;-)

[1] Évidemment, l'implémentation est sans doute ultra trouée dès qu'on utilisera un type non primitif. Heureusement, le compilo gueulera très certainement… ;-)²
[2] Et aussi, je tends à réduire l'utilisation des templates au minimum vital. Je n'y ai recours que lorsque les gains vont clairement outrepasser la chiantitude à implémenter et déboguer l'implém.

Dans ma dépêche, je réponds à toutes les questions que vous vous posez sûrement: mon mode de pensée justement n'a rien avoir avec la vanne en elle-même.

Le fait que tu rabâches la même chose depuis je ne sais quand montre quand même que « tu t'en fiches du karma », mais comme tu as l'air de mal comprendre comment il fonctionne (il faut que BEAUCOUP de gens te moinssent pour que tu en arrives là où tu en es, et il faut que quasiment aucun de tes commentaires ne soient plussés).

Surtout que ceux qui ont lu mes remarques et qui ont pris ce temps ont très bien compris que je m'en fiche du karma mais je pense aux autres…

Les autres n'ont qu'à réagir. Ils sont grands, qu'ils se débrouillent. Qu'ils fassent comme on fait dans la vraie vie quand on veut intégrer un groupe : on observe un minimum ses us et coutumes, la façon dont les gens se comportent vis-à-vis des autres, etc., jusqu'au moment où on se retrouve à participer plus activement. Et là, ben soit on a « bien » lu la façon dont fonctionne le groupe, soit pas.

Je trouve que les gens de LinuxFR ont globalement fait preuve de beaucoup de patience avec toi. C'est justement parce que, malgré la dureté des mots (parfois), ils sont tout de même ouverts à la discussion dans l'ensemble.

Si quelqu'un se retrouve avec un karma très négatif, et que c'est injuste, et qu'il en parle, figure-toi qu'il arrive qu'on lui porte assistance. Un bon exemple est PasBillPasGates. Certains zélotes anti-MS le moinssaient systématiquement au point qu'il commençait à -2 ou -4 directement. Sauf que, même si on peut être en désaccord avec lui, et qu'il est loin d'échapper à des accès de mauvaise foi (en même temps, LinuxFR est aussi appelé trollFR par d'autres, donc bon … ;-)), en fait très souvent il avait des réponses argumentées et détaillées (je l'ai très certainement plus pertinenté que non-pertinenté au total).

Donc je répète : laisse les autres se défendre un peu. S'ils ne font même pas l'effort de gueuler s'ils estiment qu'on les brime, je ne vois pas pourquoi nous on ferait un effort pour eux.

Tu es sûr de l'enchaînement des événements ? J'avais retenu limite le contraire : Sony update le firmware et vire OtherOS. Là-dessus GeoHot, qui avait une console jamais utilisée, commence à s'y intéresser, et trouve la faille (TLB stockée en RAM, qui permet ensuite d'accéder à l'hyperviseur).

Bref, Sony a eu peur d'un piratage qui, pour autant que je sache, n'était pas évident du tout (quand on offre aux hackers un peu d'ouverture, ils ont tendance à être contents et déjà explorer ce que le truc ouvert permet de faire). En fermant leur console, ils ont précipité l'intérêt pour casser ses protections.

Seulement si tu joues ET que tu te sers de la console comme PC. Sinon pour la PS3, Sony a été forcé de permettre aux clients de la versions « fat » de pouvoir rétrograder vers le dernier firmware OTHER_OS compatible.

« basé sur » ne signifie pas « reprend tous les éléments de ». Il est tout à fait possible que Grub soit considéré plus pratique pour les développements par ex. Ensuite, Mac OS X est « basé sur FreeBSD » aussi, mais presque tous les outils de ligne de commande sont des outils GNU (gmake et pas bsd make, etc.).

C'est un peu l'objet de certaines blagues sur reddit/imgur : le fait que MS fasse sa campagne de pub sur le mode « jouez avec des gens de partout dans le monde », et en pratique, « tout le monde », ça veut dire « Amérique du Nord », une partie de l'Europe (je ne suis même pas certain que toute l'UE soit couverte), une partie de l'Asie, etc.

Ça fait un peu penser aux « coupes du monde » (baseball, foot US) qui pendant longtemps n'étaient finalement ouvertes qu'aux états US. Forcément, être champion du monde ça devient plus simple tout à coup. ;-)

Là tu vois, être à -10, c'est parfaitement justifié : pas pertinent sur ton propre sujet de journal, pleurnicheur (si si, tu peux dire que tu ne fais constater les faits, tout ça, n'empêche que tu pleurniches), et limite condescendant.

Ensuite, penser que « kadalka, c'est tabou ici » c'est penser bien trop de ta personne. Même si c'est une « blague », ça explique pas mal ton mode de pensée en ce moment.

Passer de -10 à +10, peut-être pas (quoique je suis certain d'avoir vu la chose arriver ici même). Par contre, passer d'une note très négative (même -10) à +5/+6, ça arrive tout le temps. C'est juste que les mecs pas d'accord (rarement ceux qui pensent que c'est pas pertinent) sont passés avant les autres (ceux qui sont d'accord, et ceux qui pensent que le contenu est pertinent sans être forcément d'accord).

Soit dit en passant, on s'en fiche un peu qu'Intel bosse plus sur Linux que sur F/BSD ou autre OS. Tout simplement parce que le matos de la PS4 et de l'X-Box One tourne sur de l'AMD (d'ailleurs tu as bien mis un lien vers AMD dans ton journal).

Ensuite, grosse surprise, AMD travaille AUSSI plus sur Linux que F/BSD. Mais je ne vois vraiment pas où est le problème. Soit Sony a des programmeurs systèmes expérimentés, et Linux, F/BSD, etc., ça ne les dérangera pas plus que ça; soit pas.

Je ne comprends pas bien.

Soit je peux déterminer, à la compilation, la valeur d'une variable dont je veux limiter la plage de valeurs. Dans ce cas, je ne vois pas bien où est le souci (un peu de méta-programmation avec les templates permettra de régler le problème, un peu comme avec la solution d'utiliser les « static asserts » de Boost, Loki ou autres bibliothèques). Soit on ne connaît pas la valeur de la variable à la compilation, et oui bien entendu il faudra évaluer à l'exécution. Mais je ne vois pas en quoi ce serait différent avec Ada.

Si je fais

typedef enum { Lundi, Mardi, Mercredi, Jeudi, Vendredi, Samedi, Dimanche } day;
Range<day,Lundi,Vendredi> work_week;

Je ne vois pas trop ce qui est gênant (contrairement au C, C++ n'acceptera pas qu'on substitue un int à un enum n'importe comment).

Oui, j'aurais dû être plus précis, car c'était bien là que je voulais en venir.

Je ne sais pas ce que « compilateur parallèle » signifie. Intel a une option de parallélisation « automatique » qui n'est mise en œuvre que lorsque les boucles sont triviales à paralléliser (pas de dépendance portée sur plus d'une itération, etc.). Sinon, icc comme gcc implémentent OpenMP, qui nécessite une parallélisation explicite d'un programme écrit en C/C++ (ou Fortran avec ifort/gfortran).

Alors j'ai une remarque et une question.

Ma remarque d'abord :

Je trouve ça remarque pertinente

"sa" (désolé mais ça me piquait les n'œils).

La question ensuite :

Bien que je sois d'accord sur l'utilité évidente d'établir des plages de valeurs pour un « même type » directement dans le langage, au final ça revient malgré tout à créer deux types différents et laisser le système de typage (fort) faire son boulot. En C++ on ferait sans doute ça en créant une interface avec template, quelque chose qui aurait une interface du genre:

typedef Range<unsigned,0U,65535U> u16; // on pourrait sans doute faire sans le unsigned

… Avec toutes les opérations de surcharges d'opérateurs qui vont bien œuf corse (qui peut être facilité grâce à l'utilisation de Boost). Au final le système de typage ferait aussi son boulot.

Certes la syntaxe est peut-être moins sexy, mais le résultat (et surtout l'utilisation !) serait la même (une exception serait lancée si on tente d'affecter un nombre trop grand à un entier de type u16 par ex). Mon exemple montre même un cas qui serait sans doute résolu à la compil, comme en Ada.

Seulement si la quantité de travail à lui fournir ne varie pas. Ce qui généralement n'est pas le cas pour les centres de calcul (modèles plus précis nécessitant plus de puissance de calcul, ou bien tout simplement même modèle, mais avec une machine plus puissante, on traite des problèmes plus gros).

Ensuite, dans de « vrais » centres HPC, un cluster dure quand même au moins cinq ans. Étant donné le nombre de personnes qui l'utilisent, ça reste correct.

Je parle des implémentations de référence de Python (et oui, Ruby et Perl ont le même problème). IronRuby, IronPython ou Jython sont des exceptions, et quelque part c'est triste à dire, mais ils introduisent une incompatibilité si tu fais du « vrai » multithreading avec (techniquement, Python permet le multithreading pour le multiplexage des E/S). Donc je maintiens ce que je dis : Python, celui utilisé à peu près partout, ne supporte pas un multithreading « général ».

En même temps, une "université" US n'est pas du tout la même chose qu'une "Université" Française.

Nous sommes d'accord. En plus, je crois bien que ma fac veut vendre du temps de calcul aux boites alentours… ;-)

A moment, ils voulaient créer l'université de Paris, en fusionnant tous les numéros pour augmenter leur masse critique. Ainsi chaque université pourrait avoir son cluster mais réellement utilisé. Ou alors, il faut rendre obligatoire la disponibilité du cluster pour d'autre université pour les creux.

Houla, je ne pensais même pas jusque là. L'admin dont je parlais ne parlais QUE de sa région géographique. Il avait en tête deux universités (dont l'UTT) et un centre de recherche, qui pour des raisons plutôt « territoriales » voulaient chacun LEUR centre.

Vous avez combien d'admin pour les 2 noeud de calcul ? Cela ne serait pas mieux mutualisé, si les noeuds était à l'Idris ?

Dans le cas des nœuds AMD, le cluster complet a une équipe de sysadmins. Ça fait partie des coûts mutualisés d'infrastructure.

Dans le cas du nœud Intel, seul notre labo y a accès et donc nous nous chargeons de faire l'admin. Je suis dans un labo de « computer engineering », donc nous faisons plutôt la programmation de couches basses, et ça nécessite de pouvoir activer/désactiver certaines fonctionnalités du matériel, ce qui évidemment est impossible si on n'a pas un contrôle total du nœud de calcul (ce qui est le cas avec la machine AMD).

J'ai l'impression que les fac font leur tambouille juste pour éviter de la gestion administrative. Je me trompe ?

Je ne pourrais pas te dire. Je bosse dans une fac US. Dans notre cas je ne pense vraiment pas. Le cluster est réellement utilisé autant par les chimistes que les mécaniciens ou les informaticiens.

Après, je me souviens avoir discuté avec un admin (bossant à Troyes je crois bien), qui se désolait du fait que chaque fac ou centre de recherche voulait son cluster (qui du coup va être occupé à 25%), alors qu'il serait tellement plus économique qu'elles mutualisent les ressources et achètent un seul cluster partagé, avec une équipe d'admins uniques…

[à propos de l'overhead MPI dont les équipes HPC veulent se débarrasser] J'en suis persuadé, mais vous ne réutilisez jamais de code commun ou générique écrit uniquement en MPI ?

Si bien sûr, mais un bon runtime MPI va utiliser des segments de mémoire partagée pour éviter la duplication inutile de files de messages, lorsqu'on est en intra-nœud. Ensuite je me répète, mais si les centres de calcul utilisent de l'InfiniBand (ou du Quadrics pour les plus fortunés), c'est aussi parce que pour un débit pas forcément beaucoup important que du Ethernet 10Gbps, on a une latence inférieure de plusieurs ordres de grandeur… Et aussi que la fiabilité de ce genre de réseau comparé à Ethernet est bien meilleure.

Je parlais de java parce qu'on dit tant de bien de lui, alors que personnellement je n'ai jamais été convaincu par ce langage dès l'instant où python est arrivé.

Tu viens de démontrer une grande ignorance avec cette phrase. Python est arrivé en 1991. Java, bien qu'existant plus ou moins en interne chez Sun à ce moment, n'était même pas encore disponible pour le grand public (et puis, histoire d'être complet, Perl existe depuis 1987).

De plus tu ne connais visiblement pas bien les limites de chacun de ces langages. Java permet de faire du vrai multi-threading, pas Python.

Mon labo a acheté un nœud de calcul AMD (Bulldozer), 4 sockets, 12 cœurs par chip (techniquement 2×6 cœurs, m'enfin…), 128GB DDR3. Je crois que ça nous a coûté dans les 6000$ en tout. Certes, le cluster a été acheté par la fac, et ensuite les nœuds sont mutualisés : un nœud acheté par une entité pourra être utilisé par d'autres s'il est idle, ce qui je trouve est normal. Par contre, si je pousse du boulot sur notre file d'attente perso, alors j'ai priorité. Et aussi, tout ce qui est stockage a été mutualisé (avec du Lustre, etc.). Donc mon labo n'a pas eu à supporter le coût d'achat initial de l'infrastructure. Par contre, comme c'est un modèle extensible, on pourrait racheter un nœud si on le désirait. Je trouve que c'est un bon compromis : on fait payer l'infra à un groupe d'entités (en pratique, il s'agit ici de la fac pour laquelle je bosse), et on paie individuellement pour certaines ressources, à un prix correc'.

À l'opposé et pour aller dans ton sens, nous avons aussi acheté un nœud de calcul quad-socket pour SandyBridge (24 cœurs/48 threads en tout), avec aussi 128GB, et un peu de stockage. Celui-ci nous a coûté aux alentours de 10 000$, et en plus il faut que nous l'administrions nous-même.

Enfin, tout dépend œuf corse des applications à faire tourner. Pour certaines, la latence, tout autant que le débit, sont importants (je pense notamment aux applis qui font dans l'algèbre linéaire creuse, ou bien certains parcours de graphes, etc.). Pour d'autres, Ethernet suffit largement.

Cependant dans le cadre du HPC, je peux te garantir que si tu peux te passer de l'overhead de MPI et passer par de la mémoire partagée, le gain en vitesse, bien que « juste » constant, peut être significatif (×2, ×4, etc.). Je n'irais pas jusqu'à dire un ordre de grandeur, mais parfois presque. Ce n'est pas pour rien que pour les gros clusters (genre celui de ma fac), on passe par de l'infiniband : la latence est un tueur de perfs.