lasher a écrit 2753 commentaires

Tu peux enlever les guillemets à « "modèles de programmation parallèle" ». ;-)
Plus sérieusement, tu as techniquement raison, mais ce qui est intéressant avec les langages qui offrent un modèle de programmation parallèle, c'est qu'ils ont aussi tendance à définir un modèle d'execution parallèle qui va avec. Dans le cas de C11/C++1x c'est un modèle très (trop) relâché selon moi, mais c'est parce qu'ils sont tributaires de l'existant (Pthreads en particulier, mais aussi le besoin de pouvoir laisser une machine parallèle optimiser tout un tas de trucs à sa façon).

Mais les langages/modèles de prog de type OpenMP offrent un modèle d'exécution expliquant quand une région parallèle peut être créée (modèle de concurrence), quel est le mode d'orchestration des threads (modèle de synchronisation), et comment et dans quel ordre la mémoire peut être accédée (modèle mémoire). Dans le modèle de synchro, on compte par exemple une proposition de moniteurs dans OpenMP (via la construction critical), etc. Maintenant, ça n'empêche pas qu'il reste possible d'avoir une data race, mais justement, c'est l'intérêt d'un modèle d'exécution : il spécifie un modèle mémoire. Dedans, on spécifie le mode d'adressage (au minimum, si on a une mémoire partagée ou distribuée), et le modèle de constance mémoire (memory consistency). Dans ce dernier cas, on spécifie dans quel ordre les différentes opérations mémoire peuvent arriver, s'il y a une différence entre des opérations normales ou des opérations « synchronisantes » (par exemple dans OpenMP, il y a la clause atomic; dans Java, il y a le mot-clef volatile; etc.).

De façon générale, la question n'est pas tant de savoir s'il peut y avoir un conflit sur les données partagées — dès lors que tu autorises le partage mémoire implicite, ça peut arriver. Cependant, si le modèle mémoire que tu utilises est logique/compréhensible, tu peux espérer débugger ton code plus facilement qu'avec un modèle complexe. Ironiquement, je pense qu'il est plus facile de débugger du code C++ concurrent, car data race = UB, et donc généralement ça veut dire « on laisse le matériel sous-jacent se débrouiller », alors qu'en Java par exemple, c'est plus subtil, et potentiellement le compilateur a fait des trucs pas cool (aka « des optimisations » — qui sont légales hein).

Il y a même un bouquin chez O'Reilly qui doit être un peu dépassé maintenant, mais qui était le résultat d'un cours de programmation système où les profs faisaient étudier le code de Linux 2.6 (donc pas très loin avant 3.0) et c'était il y a ~10 ans. Ça se fait « très bien » mais il y a beaucoup de boulot, et ça suppose une forme par projet où les étudiants doivent modifier un ou des aspects du noyau de façon bien précise et balisée.

Il tenait un « journal secret » sur sa page facebook qui était ma foi très sympathique à lire.

En même temps, même sans être libre, un auteur peut demander explicitement à ce qu'on retire son nom. Par exemple : on peut écrire une histoire "d’après l’œuvre de…", ou bien simplement dire que c'est "dérivé de " sans préciser les auteurs (cas de Watchmen, From Hell, etc., écrits par Alan Moore). Œuf corse, si le (ou les) auteurs en question ne sont pas consultés car l’œuvre est libre, c'est plus compliqué, car on peut redistribuer le tout massivement avant que les auteurs ne puissent demander à être retirés des crédits.

Mais globalement que les solutions envisagées aient des désagrément ça ne doit surtout pas être l’argument massue pour ne rien changer.

On est bien d'accord. Dans mon exemple pour tripler la fréquence de certaines lignes, il y a déjà le fait que les bus ont des voies qui leurs sont réservées (et donc limite les problèmes de trafic), mais effectivement, je n'imagine pas pouvoir généraliser ce genre de mesure sans incitation au covoiturage (comme j'en parlais auparavant). Les gens se plaignant du flicage des voitures auront raison dans le sens où on contrôlerait effectivement qu'ils ne se placent pas dans une file réservée aux transports contenant au moins 2 personnes, mais auraient aussi « tort » dans le sens où on ne cherche pas à leur interdire de circuler du tout (il faudrait toujours qu'il y ait une voie ou deux qui soit ouverte à tous de toute manière), mais bien à inciter les gens, certes en rendant la circulation en voiture plus contrainte/contraignante, à user de transports en communs.

J'avais commencé à faire une réponse plus générique, mais comme effectivement la question sentait l'exercice (et avec le recul, au vu des questions supplémentaires qui ressemblent plus à des exigences), j'ai préféré donner une solution « littérale » pour la chaîne donnée.

Ceci étant dit, il y a plusieurs façon de faire. Par exemple :

s/c;1;2;3/c 1 2 3/

(Comme tu parles d'une chaîne spécifique, je donne une solution spécifique)

Si tu parles de « banalités » dans le sens « c'est malheureusement une conséquence banale de la vie dans les transports d'IdF » je ne peux qu'acquiescer. Mais si c'est pour en gros rejeter cet argument, au prétexte que ça ne nous dit pas « comment on s'en sort », je trouve ça bien condescendant : « on s'en sort » aussi en prenant en compte les contraintes de chacun et en essayant de trouver un compromis. Si mon pote avait un bus qui allait dans son coin à des horaires et fréquences corrects, même si le RER ne se pointait pas, il aurait au moins cette alternative pour rentrer chez lui.

Pour moi, la solution est de tripler la fréquence des bus, car dans le court terme, c'est le seul transport public qui peut être triplé en fréquence sans pour autant nécessiter d'énormes travaux au niveau des infrastructures. En plus des voies de bus/taxi, on pourrait aussi faire comme en Californie, et limiter certaines voies au covoiturage (dans certaines villes c'est déjà en train ou bien déjà mis en place). Ça veut aussi dire fliquer bien plus les voitures sur la route (et les radars automatiques ne pourront pas vraiment aider dans ce cas). Évidemment comme d'habitude, le problème tient aussi aux coûts.

Dans le moyen terme, au moins en IDF, ce qui aiderait pour de vrai serait que le grand Paris se fasse en temps et en heure, mais on sait déjà que c'est compromis (surtout avec les JO qui se pointent…).

Le problème étant que, lorsqu'on fait des journées de 10-12 heures comme le pote en question, si les trains roulent normalement, alors pas de souci, mais si à l'heure de pointe le train se traîne, et qu'en heure pas-de-pointe il se pointe pas du tout, ben la journée qui allait déjà être de 12h mini (transports et pause déjeuner compris) devient une journée de 13 ou 14h.

C'est aussi pour ça que j'ai commencé par expliquer que le pote en question avait tout d'abord tenté de venir en transports. Il n'était pas spécialement fan de devoir payer une assurance auto, l'essence, etc. Mais au final, ça lui rend la vie tellement plus simple (parce que non, il ne peut pas simplement changer de boulot, ou d'appart : il est en couple, et il n'est pas le seul impliqué dans la décision du lieu de vie).

[À propos de changement d'inconvénients pour des niveaux de nuisance comparable] C’est acceptable, globalement si les problèmes sont de désagrément similaire mais que la collectivité y gagne globalement

Je suis d'accord avec toi sur le principe. Sauf qu'il ne faut pas s'étonner que les individus décident de choisir ce qui rend leur vie à eux plus simple si les moyens existent. Dans le cas de mon pote, le soir après 20h (donc plus en période d'heure de pointe), il met moins d'une demi-heure en voiture pour arriver dans son quartier, et ensuite moins de 10 minutes pour trouver une place pour se garer en moyenne. Rajoutons aussi 5 minutes de marche à pied pour rentrer chez lui. Soit au total ~45 minutes. En RER (qui se trouve à ~5 minutes à pied de son boulot), il mettrait déjà ~45 minutes rien qu'en transport, plus 10 minutes pour rentrer chez lui depuis la gare. En soi, mon pote était OK pour « perdre » 15' le matin et idem le soir en transport, mais à condition de pouvoir rentrer chez lui à des horaires corrects (i.e., vers 21h). Ben en RER, il ne rentre pas avant 21h30, en fonction du bon vouloir du réseau transilien.

Un autre exemple bête : je suis un fervent défenseur des transports en commun (que j'utilise tous les jours — je n'ai pas et ne veux pas de voiture). Hé bien, malgré tout, plus jamais on ne m'y reprendra à prendre les bus PC1/PC2/PC3 (qui font des arcs de grands boulevards autour de Paris), même si en théorie ce sont les moyens les plus courts pour aller de mon ancien chez moi parisien jusque chez certains amis : je n'ai pas spécialement envie de respirer l'odeur des aisselles de mes voisins, et les miennes ne doivent pas sentir bien meilleur à leurs narines non plus. On y est ultra-serré, on manque de rater son arrêt tellement il y a de monde devant soi, etc. Évidemment, si magiquement la fréquence de ces bus pouvait être doublée ou triplée, peut-être que je reconsidérerai la chose, car on pourrait respirer un peu mieux dans le bus. C'est le même problème sur certains segments de certaines lignes de métro ou de RER aux heures de pointes (RER A & B vers les Halles, ligne 13 près de la Fourche, ligne 7 près de Maison Blanche, je vous vois !). Peut-être que c'est un problème purement francilien, mais avoir l'impression d'être parqué comme du bétail à certaines heures est vraiment désagréable, et franchement, fuck le bien de la société dans ces cas précis.

J'expliquais les difficultés d'un pote qui s'était résolu à acheter une voiture car les transports en commun n'étaient pas fiables/prenaient trop de temps dans son coin. On m'a répondu « bah alors il n'a qu'à habiter plus près de là où il bosse ! » C'était un autre pote, alors je n'ai pas décidé de lui foutre ma main à la gueule. Le côté « faisons fi de toute contrainte extérieure histoire de rendre le problème simple à résoudre », ou encore « explique moi ton problème je te dirai comment le contourner avec une méthode au moins aussi désagréable que le problème initial, mais différent » est bien représentative de certaines personnes malheureusement.

Je réponds très tard, mais selon moi, ce qu'on apprend sur la documentation de code, etc., vient principalement pour 2 raisons:

1. Tout le monde n'est pas un real programmer¹: pas mal de gens sont « moyens » en termes de programmation, et ont besoin d'une doc « à part » pour pouvoir rapidement trouver la doc des interfaces².
2. Il y a des environnements où le turnover est plutôt énorme (et en France c'est encore plus vrai) : sans une doc un minimum plus détaillée que la « méta-doc » évoquée, tu te retrouves potentiellement avec une catastrophe ambulante…

La combinaison des deux points précédents peut être fatale je pense.

Ce n'est pas exactement la même situation : comme je le dis un peu plus bas :

• Pendant toute la période où parcoursup était ouvert, tout était ouvert 24h/24 (nuit comprise donc)
• Au mieux, on pourrait imaginer que si la date limite est le jour X du mois Y, alors on peut soumettre jusqu'à 23:59:59 au jour X.
• En pratique, on doit considérer que tout le monde n'a pas forcément accès à un PC hors heures « normales » de bibliothèques, etc., donc avoir une deadline qui correspond aux heures administratives ne me semble pas complètement déconnant. Ça correspond possiblement aussi aux horaires où du personnel peut régler des problèmes/pannes si jamais elles ont lieu, car encore officiellement au bureau.

L'image que tu postes n'est pas franchement pertinente selon moi : il ne faut pas oublier qu'on parle du dernier jour pour la soumission de vœux d'élèves, et en particulier de la dernière heure (ou des deux dernières heures). Alors oui, les élèves (et les étudiants ­— et, soyons honnêtes, beaucoup d'adultes en règle générale) s'y prennent souvent à la dernière minute, mais autant on peut conspuer l'administration car elle n'a pas prévu le cas de grosse montée en charge en prévision du dernier jour (et du coup il s'agit surtout de prévoir que pendant 8h d'affilées, on aura une grosse charge quoi qu'il arrive), autant dire « ouin c'est pas juste, moi je peux me coucher plus tard que d'autres » ça me semble un peu ridicule : parcoursup était ouvert dès le 22 janvier.

TL;DR: gueuler contre le SI de parcoursup car ils n'ont pas supporté la charge du dernier jour de soumission, je comprends. Gueuler contre le fait que ça se termine arbitrairement à 18h (heure où plus aucun personnel ne peut aider si y'a plantage/problème), je trouve que c'est un peu de la chouinerie.

Dans tous les cas, il ne s'agit pas de niveler par le bas, ni de nier leurs spécificités aux usagers (ce qui est le thème de l'image postée).

Pour faire vite : tu supposes que tout le monde a accès à un ordinateur avec une connexion internet (décente) h24. Sauf qu'on ne peut pas nécessairement faire cette supposition pour des particuliers dans le cas général.

D'ailleurs, je me souviens qu'il y a vingt ans quand j'ai utilisé l'équivalent de l'époque, l'échéance était à minuit. À 22h, le serveur (Minitel) était saturé mais à 23h30 il n'y avait plus de problème pour se connecter

Ça me semble raisonnable, mais il ne faut pas oublier que même il y a 20 ans, on pouvait louer/emprunter un minitel gratuitement aux P&T (pas d'abonnement) tant que c'était la version noir et blanc.

Pour donner un exemple dans un autre domaine : je donne cours en IUT. J'aimerais bien pouvoir supposer que tous mes étudiants ont un ordinateur (fixe ou portable) chez eux, et du coup leur dire « vous pourrez finir le TD [ou le TP] chez vous ». Sauf que je ne peux pas, car ce n'est pas équitable pour tous mes étudiants.

Enfin, il ne faut quand même pas oublier que toutes les autres nuits et tous les autres jours qui ont précédé la date limite on pouvait soumettre à n'importe quelle heure.

Tu as raison, mais après, typiquement, pour les JPO, les facs/prépas/etc. font exprès de les organiser en Décembre/Janvier/Février justement pour que ce soit encore « frais » dans la tête des lycéens et de leurs parents.

Concernant les choix entre prépa, STS, IUT, fac, etc., comme tu as 10 choix (sans compter les sous-choix dans une catégorie donnée), tu peux relativement facilement les inscrire. Il s'agit vraiment principalement d'un problème de méthode à la rache™.

C'est aussi vrai dans le supérieur, soit dit en passant. Enfin, pas moi, hein, mais les autres… O:-)

En l'occurrence, donner une deadline ferme, c'est aussi un problème d'équité/égalité devant tous les candidats : tout le monde est traité de façon égale. Parce que si on suit ton raisonnement, alors bon, franchement, 19h ou 20h, tant qu'il est pas 8h ou 9h du mat', heure à laquelle on va peut-être commencer à examiner les dossier, on s'en fout non (hint : non, on ne s'en fout pas) ?

Sauf s'il est de connivence avec d'autres collaborateurs (souvent passés) ou potes, un chercheur qui a son nom sur une publi, ça veut dire l'une des choses suivantes dans mon expérience :

• Il a effectué la majeure partie de la recherche (si c'est un « vieux » chercheur, ce serait étonnant — c'est à ça que servent les thésards [pour se former] et les jeunes profs [parce qu'ils n'encadrent pas forcément encore de thésards] !)
• Il a encadré ou dirigé une ou plusieurs personnes qui ont fait le travail en pratique (ça implique des réunions de travail, de faire des critiques constructives, etc.)
• Il est officiellement le directeur de thèse d'un des « vrais » auteurs du papier. C'est à différencier d'un « simple » encadrant : au moins en France (et dans d'autres pays aussi, comme en Chine par ex), être maître de conférences ne signifie pas qu'on a le droit de diriger la recherche d'un thésard de bout en bout. Il faut aussi avoir obtenu une HDR¹. Du coup dans plein de labos français, on a un directeur de thèse officiel (mais qui ne suit pas vraiment le travail du/des thésards), et des encadrants qui font le vrai boulot de formation². Sauf que du coup il faut bien que le directeur figure sur la liste des auteurs quand même, car c'est quand même souvent grâce à lui (enfin, à son nom) qu'un financement a pu être débloqué, un projet (et donc les sous qui vont avec) accepté, etc.

Un autre cas qui arrive de temps en temps : un des co-auteurs parle de sa recherche à quelqu'un (directement, ou bien lors d'un séminaire par exemple), et ce quelqu'un fait une remarque qui permet de débloquer une situation. Suivant le degré de pertinence de la remarque, et à quel point elle permet d'avancer sur le travail, ce genre d'aide peut être reconnu dans les remerciements en fin d'article, voire on peut proposer à cette personne d'être inscrite en tant que co-auteur (et généralement on lui donne alors un droit de regard sur l'article lui-même, et la personne peut aider à la rédaction).

EDIT: j'oubliais aussi le cas où il s'agit d'une collaboration entre différentes équipes ou labos, et où l'un des chercheurs n'a pas forcément un rapport direct avec la recherche, mais où les ressources permettant d'accomplir la recherche se situent dans son labo : nœuds de calcul (avec la partie sysadmin qui va bien), etc. (souvent ce genre de chercheur a aussi participé à la rédaction du dossier de demande de financement…).

Tout ceci étant dit, je connais des chercheurs qui continuent de chercher même à 80 ans passés, et qui publient encore en tant que premier auteur. Alors certes, leurs travaux les plus impressionnants ont été faits il y a plus de 40 ans, mais ils continuent d'améliorer leurs résultats incrémentalement (et pour au moins l'un d'entre eux, de coder eux-mêmes leurs simulateurs…).

D'ailleurs, J.Oliver se garde bien de se faire appeler journaliste (même si en pratique il fait sans doute un bien meilleur job que la plupart des journalistes US, au moins sur les sujets qu'il traite). Il se qualifierait sans doute plutôt d'humoriste…

OoOoOoh, je ne connaissais pas. Merci ! :)

Meltdown et Spectre sont si loin que ça dans les mémoires?

Du point de vue macro, les processeurs font effectivement ce qu'on leur demande : ils exécutent le code qu'on leur donne, et même s'ils utilisent la spéculation pour aller plus vite, les instructions exécutées qu'il ne fallait pas exécuter sont jetées avant que leur résultat ne soit visible pour l'utilisateur. Dans le cadre de Meltdown, le problème est réellement un « bug » de conception, car les processeurs Intel (et certains processeurs haut de gamme ARM) permettent de charger des pages noyau en cache en passant outre les bits indiquant qui a le droit de lire ce genre d'information¹. C'est donc un vrai gros défaut de conception qui dit fuck à la sécurité au nom de la performance (et qu'AMD a évité apparemment). Donc, même si ce n'est sans doute pas une faille voulue par Intel/ARM, c'est quand même un gros manquement en termes de conception.

Dans le cadre de Spectre, c'est différent : on se retrouve avec un algorithme d'exécution dans le désordre (l'algorithme de Tomasulo, qui se base sur les principes d'exécution par flot de données). L'exécution dans le désordre en elle-même n'est pas un problème : si j'ai des instructions qui mettent en œuvre des unités fonctionnelles différentes (UAL, FPU, possiblement des composants spécialisés pour accéder à la mémoire, etc.), du moment que ces instructions auraient été exécutées de toute façon, les exécuter dans le désordre pour gagner du temps n'est vraiment pas un problème. Ce qui est gênant en termes de sécurité, c'est la spéculation d'instructions, car on va chercher des informations au-delà des plages d'adressage autorisées pour un programme donné lors de branchements directs ou indirects, ce qui du coup court-circuite (pour les processeurs courants) droits d'accès.

Du coup autant Meltdown exploite une erreur relativement grossière de conception, autant pour Spectre c'est plus nuancé je trouve (ça n'empêche pas de devoir corriger les deux failles en question bien entendu).

C'est littéralement ce que nous nous disions dans mon labo y'a ~10 ans lorsqu'on a vu des papiers montrant qu'on pouvait récupérer les clefs privés de GnuPG en passant par des side-channel attacks sur le cache : « dans la vraie vie y'a trop de bruit sur un serveur à cause de tous les processus qui tournent pour que ça puisse marcher ». Et bim, 10 ans plus tard, Spectre et Meltdown arrivent.

En l'occurrence, la notion d'analyse du prédicteur de branchement et d'utilisations d'attaques par timing pour récupérer des infos du cache de données avait déjà été abordée dès 2005-2007. Voir ici par exemple.

EDIT: pas vu une autre réponse plus complète que la mienne…

Petite correction : Apple n'est pas « pas mal à l'origine de LLVM ». En fait ils ne le sont même pas du tout. Ils embauchent le mec qui a écrit LLVM, (grosse) nuance. LLVM en tant que tel est un compilateur qui a été financé par la National Science Foundation, sur la prémisse qu'il n'y avait pas de compilateur dont l'architecture était moderne et favorisait la recherche pour les techniques de compilation, et en particulier la recherche pour les transformations optimisantes indépendantes de l'architecture cible.

Par contre depuis, et en partie grâce/à cause du passage de GCC de la GPLv2 à GPLv3, Apple a largement contribué à LLVM, c'est vrai.

Sinon comme le disaient d'autres personnes, toutes ces boites participent toutes à de gros développements pour du logiciel libre (mais évidemment c'est parce que ça leur permet de garder un certain contrôle sur comment certaines briques essentielles sont développées, et malgré tout de mutualiser une partie des efforts).

Je réponds à la bourre, mais :

Je suis convaincu que GCC (ou n'importe quel compilateur) n'est pas capable de parser certains fichiers C parfaitement valides (mais complètement tordus).

Si tu actives certaines optimisations qui créent des graphes complexes (en gros, -O3 avec quelques options en plus par exemple) tu peux clairement arriver à des plantages du compilateur pour certains codes. Par exemple, le fameux code de ffmpeg a quelques fonctions qui font 3000 lignes pour cause de programmeur ne faisant pas confiance au compilo. Bon ben, si jamais on activait les directives de compilation et vectorisation dessus, on pourrait avoir quelques surprises, euh, intéressantes. :-)

Sinon, avec le compilateur d'Intel, il m'est déjà arrivé d'avoir des plantages du genre « Internal error : graph too deep » (ce n'était pas exactement dit comme ça, mais c'est plus ou moins ce que ça veut dire) : c'était la représentation interne du programme en activant toutes les grosses optimisations qui faisait que le compilateur finissait par faire trop de récursions en parcourant/mettant à jour le graphe…

En même temps, quand tu vois que GNU sort alloue (allouait ?) des GIGA octets histoire d'avoir toujours de la place quand il en a besoin (et qu'il s'appuie sur l'allocation de pages à la demande effectuée par le noyau en pratique), Debian a bien raison…