lasher a écrit 2738 commentaires

Avec un Bac général et un échec retentissant à la fac comme on en voit de plus en plus, en raison de la baisse du niveau du bac […]

Bon, ce discours du « bac qui ne vaut plus grand chose » a tendance à m'énerver un chouïa. Le bac tel qu'il était passé dans les années 60 et 70 n'a plus rien à voir en termes de finalité avec l'actuel bac. Le premier était obtenu difficilement, après avoir passé le concours d'entrée en 6è, puis en 2nde, puis avoir passé la première partie du bac en 1ère, puis la deuxième en Terminale.

Le niveau global demandé au bac de nos jours n'est ni meilleur ni moins bon qu'il y a 50 ans. En fait je trouve très difficile de comparer les deux, étant donné la sérieuse différence entre un système qui globalement fonctionnait à l'élimination à la moindre erreur vs. le système actuel qui essaie d'élever le niveau global, quitte à faire doubler l'élève. Dans tous les cas nous avons un système relativement compétitif, mais l'ancien l'était dix fois plus que maintenant. Les maths sont plus « faciles » maintenant qu'avant dans les sections scientifiques ? Peut-être. Nous avons malgré tout énormément de très bons scientifiques au final en proportion ET en nombre absolu. Les contenus ont aussi énormément évolué, à mesure que notre connaissance du monde (sociologique, anthropologique, physique, biologique, etc.) a évolué. Quelqu'un qui prend des cours au lycée de nos jours doit composer avec une réalité très différente de celle que j'ai connue il y a ~15 ans quand j'étais au lycée, et encore plus différente d'il y a 30-40 ans. Ne pas accepter ça et vouloir comparer les épreuves de nos jours, avec les réalités et difficultés actuellement rencontrées sans mettre en perspective la réalité différente de l'époque, c'est faire preuve d'anachronisme.

Ceci étant dit, c'est bien parce que l'obtention du bac a largement augmenté qu'on ne peut plus juger la « valeur hiérarchique » bien pratique pour les entreprises. Pour effectuer un boulot « équivalent » à ce qui aurait été demandé il y a 30-40 ans, on demande désormais une licence minimum.
Le bac, lui, a remplacé le BEPC/brevet des collèges, en ce qu'il garantit la capacité d'une personne à savoir lire, écrire, et compter, et donc la certifie apte à exercer un métier non qualifié.

Quelle que soit la difficulté « réelle » du bac comparé à son homologue des années 50-70, l'épreuve en elle-même reste sans doute unique en son genre comparée aux autres pays occidentaux : on « séquestre » des millions d'élèves, six à huit heures par jour pendant une à deux semaines, et on les force à poser leur cul sur une chaise et l'Éducation Nationale attend d'eux qu'ils soient au top de leur forme, mentale et physique pour répondre à tous les sujets.

Enfin, en ce qui concerne l'échec en fac, cela vient surtout du fait (à mon avis) que, lorsque le collège unique a été créé en 1975, avoir « juste le bac » était malgré tout toujours suffisant pour obtenir un boulot avec des perspectives d'avenir. La fac (et encore moins les filières sélectives type IEP ou écoles d'ingénieur) ne s'est donc pas réellement sentie obligée de s'adapter à ces étudiants qui n'étaient pas tous issus du même moule : elles ont suivi un processus darwinien drastique, façon « après moi, le déluge ». Ce n'est pas pour rien que dans les IUT et BTS (entre autres), certains profs de maths, etc., sont aussi profs au lycée : ils sont le « pont » qui permet aux enseignants du supérieur (fusse-t-il technique/professionnel) de savoir ce que les élèves apprennent réellement, et quelles méthodes ils connaissent en réalité.

Si, aussi. C'est le problème d'écrire bourr… tard le soir. Tu as tout à fait raison : réutiliser la même donnée en mémoire relève de la temporalité, alors que bénéficier du fait qu'une ligne de plusieurs mots sont chargés lors d'un cache miss relève de la spatialité.

Pour répondre aux deux en même temps : « prédication » et « prédicater » sont deux barbarismes en Français. Par contre les deux termes sont utilisés en permanence en Anglais et dans les labos info, de la même manière que tout le monde dit « je préfetche la ligne, là, et … », et pas « je précharge la ligne ». :)

"Decode → Execute → Memory" n'est clairement pas un "risc".

J'ai oublié de relever : ça par contre je ne comprends pas. C'est un peu l'archétype de l'architecture RISC. Il y a simplement des moyens de faire un « forward » d'un étage à l'autre. C'est aussi ce qu'explique la page Wikipedia sur le pipeline RISC classique, ainsi que le Hennessy et Patterson (Hennessy est le monsieur derrière MIPS, donc je pense qu'il sait de quoi il cause…).

Donc l'étage « EX » peut être simplement le calcul d'adresse, et « Mem » l'accès effectif à cette adresse. Ensuite, « WB » sera utilisé ou pas (par exemple, si on fait un load, il faut bien écrire la valeur chargée dans un registre quelconque…).

Je comprends ce que tu veux dire, mais la raison pour laquelle beaucoup de gens (dont moi) disons que ce n'est pas du « vrai » CISC c'est vraiment parce que la notion de pipeline est intrinsèquement liée à l'architecture. Comme le dit Nicolas plus bas, Intel a mis le paquet pour que ça reste du CISC grâce à son décodeur (jusqu'à 6 instructions CISC décodées par cycle, c'est vraiment impressionnant).

Donc d'un côté je comprends ce que tu veux dire, et je ne peux qu’acquiescer; de l'autre, l'ISA d'un processeur donne généralement de gros indices sur la façon dont un processeur est architecturé. Les deux exceptions (pour moi) sont Intel/AMD avec leur version de x86 (mais comme je le dis plus bas, dès qu'on parle de performance, on revient à des programmes de type RISC avec séparation load/store et arithmétique), et Nvidia (avec PTX, une ISA « virtuelle », et dont la programmation « à la main » peut accélérer fortement les perfs d'un programme pour une version donnée d'une carte, et devenir médiocre pour la version suivante).

En pratique, lorsque j'avais du code SIMD à écrire en assembleur, je devais l'écrire « façon RISC » pour obtenir la meilleure performance (donc séparation des load/store, des opérations arithmétiques, etc.). C'est aussi (à mon avis) parce qu'il s'agit d'instructions plus récentes et qui donc peuvent se « permettre » d'être plus proche de la « réalité architecturale ».

Perdu, les banc de registres à fenêtre , c'est pour les appels de fonctions

Oups. L'idée était la bonne, la finalité non. Ensuite pour le « flush » oui, il faut bien le faire à un moment s'il n'y a plus de fenêtre de registre disponible. Je n'en ai pas parlé, mais parce que je trouvais ça évident.

Merci pour la correction !

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.