lasher a écrit 2743 commentaires

Je vais me répéter vis à vis de ce que j'ai déjà dit dans un autre trol^Wjournal il y a des mois/années de cela mais … Au début du XXè siècle, les garçons étaient « naturellement » doués pour les lettres classiques (Français, Latin, Grec ancien), ces matières-mêmes qui garantissaient l'entrée pour des études prestigieuses telles que médecine, droit, etc. Lorsque la physique moderne, le génie électrique, et bien plus tard l'informatique & l'électronique se sont développés, alors bizarrement, il était œuf corse évident que les garçons avaient un penchant naturel pour les maths là où les filles ne l'avaient pas. Pour citer Stella Barúk (grande pédagogue, qui se spécialisait dans l'enseignement des maths aux enfants en difficulté): il n'y a pas de bosse des maths, pas plus qu'il n'y a de nul en maths; il y a seulement des enfants qui ont besoin qu'on leur explique différemment.

Je trouve cela d'autant plus intéressant que le premier compilateur fut conçu par une femme (Grace Hopper), que la première « programmeuse » fut une femme (Ada Lovelace), et que les premiers programmeurs étaient des programmeuses (car il s'agissait « simplement » de câbler correctement l'ordinateur et d'y entrer les données, soit un travail mécanique ne nécessitant pas spécialement de réfléchir, n'est-ce pas…).

Autre chose : il est intéressant de noter que dans beaucoup de matières où les hommes et les femmes sont correctement représentés (voire les femmes sont clairement plus nombreuses que les hommes) en sciences humaines, les hommes sont malgré tout plus nombreux parmi les professeurs/maîtres de conférences pour enseigner lesdites matières (encore une fois désolé, je n'ai pas les chiffres). On pourra objecter que l'ambiance « publish or perish » ultra-compétitive y est pour quelque chose. Je ne suis franchement pas convaincu. Les vieux cons dans les comités d'experts qui restent ultra-sexistes et décident de qui a le poste de maître de conférences, ce n'est pas qu'un mythe.

Je n'ai pas la source à portée de main (désolé), mais certains études ont démontré que les instituteurs avaient tendance à favoriser les élèves garçons en termes d'attention (de l'ordre de 70/30 en faveur des garçons). Lorsqu'on leur faisait remarquer, vidéo à l'appui, ils clamaient que non. Lorsqu'on leur demandait d'essayer de rééquilibrer la donne, ça donnait du 55/45, et avaient l'impression de favoriser les filles (je tiens à préciser que les profs des écoles étaient indifféremment hommes ou femmes).

Je ne pense pas une seule seconde que les gens qui veulent un rééquilibrage des populations sur le lieu de travail pour les différents postes (donc grossissant le trait, « les féministes ») nient qu'il existe des différences biologiques qui influent sur notre personnalité, notre comportement, etc. Par contre, il existe tout un tas d'études qui montrent que dès sa naissance, un enfant sera traité différemment (dès l'allaitement) s'il est un garçon ou une fille, même pour des choses qui a priori sont les mêmes indépendemment du sexe ou du genre.

Le problème du sexisme est qu'il est systémique, et que tout le monde y participe en partie (hommes et femmes). Peut-être que les différences biologiques ont un impact plus important que certains chercheurs en sciences sociales semblent croire, et peut-être qu'effectivement, même dans une société réellement égalitaire dans la façon de traiter les genres, on aurait un ratio de type 60/40 en « faveur » des garçons pour, par exemple, ce qui touche à l'informatique. Le problème est qu'on est plutôt dans des rapports de type 75/25, voire 80/20 (et je ne parle même pas de la micro-électronique).

À propos du documentaire qu'a mis en lien alenvers, je suis tombé sur une discussion intéressante qui fait l'analyse du premier épisode ici. L'un des intervenants reproche entre autres au documentariste d'avoir choisi des chercheurs de renommée internationale lorsqu'il parlait à des biologistes, alors que les chercheurs en sciences sociales danois avec qui il s'est entretenu n'étaient pas du tout du même calibre.

Car de ce que j'en sais : lorsqu'un patron veut embaucher une personne en tenant compte de son diplôme, il a tendance à accorder une moindre valeur aux noirs puisqu'ils ont eu leur diplôme « plus facilement »

Alors ça je ne sais pas d'où tu sors ça. Rentrer dans des facs peut être (pas « est ») rendu plus facile dans certains cas grâce à des bourses dédiées au minorités si on rentre dans les petites cases (et souvent, ça veut dire que tu as déjà de plutôt très bonnes notes: il faut être « méritant »). Par contre, la discrimination positive s'arrête là en termes de diplômes : on aide certaines populations à entrer dans les facs, mais le reste est complètement laissé dans les mains de l'étudiant(e).

Source : je bosse dans une fac US depuis un moment, et autant j'ai vu des profs faire des pieds et des mains pour avoir des minorités (vis à vis de notre domaine, electrical & computer engineering/computer science) dans le labo parce que c'est toujours bien de le dire quand ensuite on soumet des demandes de financements à la NSF, autant lorsqu'il s'agit de noter, on note tout le monde de la même façon.

Enfin, la bourse te garantit d'avoir tes 4 années de Bachelor (± équivalent d'une licence) financées, mais si tu n'obtiens pas assez de crédits, tu n'auras pas le diplôme (et tu devras payer pour finir).

Je ne dis pas qu'il n'existe pas de facs US qui ne gonflent pas les notes de certains (je suis sûr que ça doit arriver), mais les facs « sérieuses » / qui ont une réputation à tenir ne le font pas.

L'heritage en diamant n'est pas propre a C++… N'importe quel langage qui autorise l'heritage multiple aura ce probleme… Certains le gerent plus ou moins bien, mais ca reste problematique, et il y n'y pas de solution generale qui soit elegante.

Je suis d'accord avec ton commentaire sur le nombre de lignes de code et sa signification. Quelque part c'est significatif si tu fais les comparaisons dans le même langage (programme 1 vs. programme 2 en C++ par ex), mais même là, « less is more », tout ça.

Sinon, pour répondre à ta question:

//--------- global_header.hpp ---------//

#include <iostream>
#include <string>
#include <vector>
#include <map>
#include <queue>
#include <array>
#include <deque>
// ... etc., etc.

//--------- global_header.hpp ---------//

//---------    program.cpp    ---------//
#include "global_header.hpp"

int main(void) {
    ifstream f("test.txt");
    cout << f.rdbuf();
    return 0;
}

//---------    program.cpp    ---------//

Évidemment, c'est « pas bien » d'inclure tout ça alors qu'on ne se sert que de iostream, de même que faire des import à tout va en Python c'est mal. Mais pour du prototypage, c'est pratique (on peut toujours supprimer les #include qui manquent plus tard).

En même temps, si j'essaie d'écrire un document de type RFC en tant que petit dév C ou C++, je pense qu'on va me prendre pour un guignol, et tu penses bien qu'il me faudra l'appui de gens qui font partie du comité de normalisation pour être pris au sérieux…

En même temps, voilà quoi.

Tru64? Quelle horreur. Au moins FreeBSD tient (tenait) la route sur Alpha.

J'ai pertinenté, parce que c'est une réponse effectivement pertinente (et drôle), mais il y a malgré tout un peu de vrai dans la réponse de Foutaises.

Je ne veux pas que tout le monde revienne à l'écriture de code en C/C++ (our Fortran, ou…), ce serait une perte de productivité monstrueuse. Par contre, que les programmeurs soient un peu plus conscients des ressources que leurs programmes prennent, ce ne serait pas un mal. Par exemple, un ordinateur bas/moyen de gamme ne devrait pas être trop lent pour accéder à certains sites web 3 ans après leur achat…

Pendant les années ~70—90, la loi de Moore a permis pendant des années d'allonger la taille des pipelines d'instruction, qui a permis à son tour d'augmenter la fréquence des processeurs mécaniquement. Pourtant, la fréquence des bus, elle, ne doublait pas (elle augmentait linéairement et pas exponentiellement). Alors oui, la loi de Moore ne parle que des transistors sur une surface donnée. Mais ça a eu un impact direct sur la fréquence des processeurs pendant 2 ou 3 décennies. Mais comme on n'était pas capable de caler la fréquence des bus mémoire sur celle des processeurs, une grande partie des transistors était (et est toujours) employée à créer des caches de plus en plus gros pour masquer les latences. Donc si, la loi de Moore a eu un impact direct sur le fossé grandissant qu'il y a eu entre les processeurs et la mémoire, et la façon de gérer ce dernier.

En même temps, Intel est sans doute le fondeur qui produit les processeurs avec le plus gros nombre de transistors au mm². Ils ont un processus de production monstrueux, et je ne sais sincèrement pas s'il existe d'autres fabricants aussi efficaces en termes de miniaturisation pour des processeurs haute performance (ce qui généralement implique des processeurs avec tout plein de transistors …).

Aparté: je sais qu'on parle beaucoup des technologies à 22nm (« actuelles »), et 14nm (« futures »), mais Intel planche déjà sur les technos inférieures à 10nm (7nm en particulier). L'une des raisons est que des phénomènes physiques se déclenchent en-dessous de 10nm qu'on ne voit jamais si on ne descend pas à ces dimensions, et du coup fabriquer des processeurs avec cette taille de transistor se révèle bien plus ardu que pour les autres (qui nécessitent aussi du boulot hein, mais pas dans les mêmes proportions).

C'était pas juste une observation. Lorsque Moore parle du nombre de transistors qui double tous les 18 mois, il dit aussi que pour le moment, la tendance semble stable. Après, oui, quelques décennies plus tard, cette loi semble limite « forcée ». D'ailleurs de façon générale la loi de Moore est « bien » pour les processeurs, mais malheureusement la mémoire ne suit pas vraiment en termes de débit et latence (et je ne parle même pas de consommation d'énergie).

Un CPU au sens de von Neumann, c'est une unité centrale de traitement. Du moment que tu as un jeu de registres, une UAL, un bus de contrôle, un autre de données (qui va en mémoire) et un bus d'E/S, tu as un CPU. Point.

Pour tout le reste, ce que je comprends de ce que tu dis c'est que tu veux un CPU multi-cœur, multithreadé, avec instructions vectorielles. Tes 40 GFLOPS en simple précision, tu ne les obtiens que parce que les codes concernés sont réguliers dans les accès de données, et que tu utilises un truc genre AVX qui permet d'effectuer une opération vectorielle sur 2 groupes de 8 éléments SP. Bref, tu parles de processeurs qui sont considérés comme haute-performance. Moi aussi j'adore ces trucs, c'est même mon métier de savoir les exploiter correctement.

Ça ne veut pas dire que tous les processeurs devraient fonctionner ainsi. En fait, l'une des raisons qui a fait que l'Atom et ses potes ont commencé commercialement, c'est bien à cause/grâce à l'OLPC, qui certes utilisait une IP proprio (clone x86 par AMD ou VIA, ARM, etc.), mais qui était abordable. La fréquence était de l'ordre de 400MHz (jusqu'à 1GHz pour les modèles haut de gamme), ce qui est relativement peu. L'important était la consommation d'énergie et de puissance, histoire d'avoir une durée de vie de batterie maximale.

Tiens, une dernière remarque: la première version de Blue Gene (BG/L) était basée sur des nœuds de type PowerPC à 700 MHz. La raison était toute simple : bien qu'IBM sut faire des processeurs bien plus rapides, la mémoire, elle, ne suivait pas. Et comme l'important dans un supercalculateur, c'est le parallélisme et des latences basses bien plus que la vitesse individuelle d'un cœur de calcul, ils ont préféré avoir un système dont la technologie était quasiment complètement synchrone : le bus mémoire tournait lui aussi à 700 MHz, et les réseaux d'interconnexion entre nœuds de calculs avaient une latence qui pouvait suivre ce genre de fréquence aussi. Au final, un aller-retour entre un processeur PowerPC et la RAM prenait exactement le nombre de cycles attendus pour charger une ligne de cache (32 octets, avec un bus de 32 bits → 8 transferts = 8 cycles). En couplant cela avec des instructions de préchargement, on avait des « quasi-garanties » de ne jamais avoir de bulles dans le pipeline, sauf en cas de vraie dépendance (read-after-write), et sauf mauvaise génération de code par le compilateur bien sûr. Pourtant, le POWER5 existait déjà, et offrait une puissance brute supérieure à ce pauvre PowerPC 440 (qui est une forme de processeur embarqué).

Bon, c'est peut-être aussi ma personnalité qui est comme ça mais… Avant d'ouvrir un compte sur LinuxFR, j'ai sans doute passé ~6-10 mois à juste lire les articles et journaux (ainsi que leurs commentaires). Je fais à peu près pareil sur les forums et autres newsgroups. Tu peux considérer ça comme de l'auto-censure, mais c'est ce que je fais avec presque n'importe quel groupe de personne (IRL ou en ligne).

Pour donner une analogie un peu simpliste : lorsque j'arrive chez un nouvel ami qui me présente à ses potes, je vais rarement être celui qui initie une conversation qui ira plus loin que « salut, comment ça va ? Tu t'appelles comment ? » (avec peut-être un soupçon de « tu fais quoi dans la vie ? » et encore). Au contraire, je vais plutôt voir comment la dynamique de ce groupe d'amis fonctionne, tout en essayant de participer un peu (répondre aux questions étant un minimum). Si personne ne prononce de gros mots dans le groupe, rien ne m'interdit d'en user, mais il ne faudra pas que je m'étonne si je ne suis plus invité à fréquenter ce groupe d'amis la fois suivante (car ils m'ont trouvé vulgaire/malpoli/etc.). Encore une fois, si tu veux appeler cela de l'auto-censure, libre à toi, mais dans ce cas je ne me censure pas sur le fond, mais sur la forme : ce n'est pas parce qu'un forum est « public », dans le sens où n'importe qui peut créer un compte et participer, qu'il n'y a pas une notion d'étiquette (en dehors de celle imposée par les modérateurs du site, ainsi que les obligations légales).

Il y a toujours un risque d'acharnement de la « communauté » envers quelqu'un. Il y a aussi souvent des gens pour défendre les victimes lorsque ces dernières n'ont visiblement pas d'intentions « malhonnêtes » — le meilleur exemple est sans doute pasBillpasGates, qui a souvent été « inutilé » simplement à cause du fait qu'il bossait pour MS et qu'il corrigeait des affirmations (souvent incomplètes, voire fausses) concernant les produits de Microsoft. Zenitram l'a défendu (souvent); je l'ai défendu (parfois); d'autres l'ont défendu aussi, et tu peux être certain qu'une grande partie est en désaccord la moitié du temps avec pBpG. Malgré ça, il en a eu marre à un moment car il était traité de façon réellement injuste. Et en réaction à ça, il y a eu un (des?) journaux, etc., pour défendre pBpG, et il a finalement eu son score réinitialisé, et il lui arrive encore de temps en temps de venir commenter (et s'engueuler joyeusement avec nous).

Bref, comme tout groupe de personnes, il existe des fois où certains ne s'intègrent pas bien. Mais s'ils ont pris le temps de lire un peu comment les gens argumentent ici, ils savent qu'en fonction de qui répond, le style est plus ou moins sec, violent, abrasif, condescendant, etc., ou au contraire plutôt très ouvert. C'est toujours pareil : si tu « imites » le style des plus violents des contributeurs de LinuxFR, attends-toi à obtenir des réponses tout aussi violentes. Au contraire, si au moins au début tu restes relativement neutre, pour tater le terrain, tout en exposant tes idées, j'ai rarement vu des gens sur DLFP qui t'envoyaient bouler méchamment (gentiment, oui; ironiquement, oui; avec contre-arguments, oui; sans contre-arguments, oui; etc.).

Pour finir avec une analogie pourrie : disons qu'un pote me présente à un autre de ses potes. Mon pote dit bonjour son ami en disant « Salut connard ! » Si l'ami en question le prend bien, c'est très certainement ironique, ils se connaissent bien, et donc ne vont pas voir autre chose qu'une blague de mauvais goût potache. Si ensuite je dis la même chose, l'ami de mon pote peut à juste titre me regarder de travers, m'insulter en retour (et cette fois être sérieux), etc., et ce sera ma faute. J'aurais du dire « Bonjour » poliment la première fois, car je ne connais pas assez bien ce monsieur (ou cette dame) pour me permettre de lui parler aussi familièrement.

C'est rigolo, je n'avais lu que les 4 premiers mots (« Teradata investit dans DotHill »), et je savais déjà que ce serait un des journaux de Samuel. :-)

Tu as raison pour les micro-benches, mais si d'un côté tu ne vas sans doute pas exécuter 10000 fois le même noyau de code d'affilée, tu vas par contre réutiliser les mêmes structures de données régulièrement, en leur faisant subir plusieurs types de traitements. De ce côté-là, ça signifie que oui, tu auras au moins une partie des structures de données présentes dans les caches.

Personnellement j'aime faire les deux :

1. Une série de tests où je vide systématiquement les caches avant de faire tourner le code
2. Une série de tests où je répète le même code plusieurs fois de suite pour voir quel est la meilleure performance possible en pratique (vs. la performance théorique de la machine par exemple).

Dans le cas précis de Python, c'est beaucoup plus compliqué, car le ramasse-miettes, les mécanismes dynamiques de typage, etc., font que des traitements annexes au code lui-même peuvent se déclencher de façon complètement imprévisible.

Les deux plus grosses en fait (PS4, XBox One). C'est en fait très logique pour des consoles de jeu : avec les APU, on a de la mémoire partagée entre le GPU et le CPU, et tout est on-package/on-chip. Forcément, comme le matériel est fixe, ça veut dire qu'on peut produire des bibliothèques d'utilitaires pour les dévs de jeux qui tirent correctement parti de ce genre de technologie. C'est plus compliqué et moins évident pour ceux qui font de la programmation plus « générique ».

Il y a aussi eu l'i860, qui était un « vrai » processeur RISC produit par Intel au milieu des années 90. Par contre je ne sais pas s'ils avaient décidé de produire ce processeur juste pour le calcul haute performance, ou bien s'ils avaient des ambitions plus larges.

Des clusters d'Opteron c'était très très très courant a la fin des années 2000.

C'était le moment ou leur rapport perf / prix étaient très bon comparé a de l'IA qui n'a jamais décollé et des xeons qui étaient plus cher pour pas mieux.

Surtout, les Opterons avaient l'HyperTransport, alors qu'Intel n'avait toujours pas produit de processeurs (IA64 ou x86) avec un réseau d'interconnexion efficace. Pour le cluster du CEA (à base d'IA64), Bull avait conçu et produit l'interconnect pour pouvoir faire communiquer 4 Itanium2 sur un même nœud à mémoire partagée.

C'est une question très pertinente. Je pense que les architectures ARM sont suffisamment utilisées par des hackers pour que GCC ait un niveau d'optimisation raisonnable (sans parler du fait qu'une grande partie des transformations sont opérées dans le middle-end, qui se fout de l'archi cible). Par contre, pour le POWER8, si on n'utilise pas le compilo d'IBM, je ne sais pas à quel point GCC sait optimiser spécifiquement pour ce processeur (je suppose quand même que le « sous » jeu d'instruction PowerPC est correctement compris par gcc).

C'est mon problème avec ce benchmark:

1. Je ne sais pas quel code a été utilisé pour faire les benchmarks
2. Je ne comprends pas leurs métriques en termes de perfs (pour la puissance, c'est assez clair)

Bref, j'aimerais avoir quelqu'un qui m'explique un peu comment lire les graphes.

Non, mais mon patron a été étudiant là-bas. ;-) Il a aussi créé un concurrent à Cilk dans les années 90, du coup je connais plutôt très bien l'environnement (mes connaissances concernant LISP sont justes de la « culture générale »).

J'ai oublié de préciser un dernier truc pour Cilk (CilkPlus en fait) : depuis la version 4.8 ou 4.9, gcc le supporte partiellement (et depuis la version 5.0, complètement). Ça en fait un langage facile à tester.

Je n'ai pas d'avis sur Julia (jamais regardé de près, et encore moins utilisé).

À noter que les gens de l'université de Houston (USA) ont récemment implémenté (en libre) une version complète de la dernière norme de Fortran, y compris les CoArray, etc.

J'ait fait du Fortran orienté objet pendant 3 ans et sur un code de 15 000 lignes j'ai compris ma douleur avec -ipo. J'avais des classes avec des getter qu'il fallait absolument inliner pour la performance, d'où l'utilisation de -ipo. Malheureusement, avec ce code qui restait de taille raisonnable, la passe -ipo prenait parfois 20 minutes :-(. Donc, -ipo est à utiliser avec parcimonie.

L'option d'inlining inter-procédural est à utiliser quand tu es certain que ton code est correct, et qu'il est déjà bien optimisé avec -O3. Une fois que tu as cette garantie, alors ça vaut le coup d'utiliser -ipo, car a priori tu ne l'utiliseras qu'à la toute fin, quand tu es (quasi-)certain que tu ne vas pas retoucher au code de sitôt.

Après, tu peux toujours spécialiser le code via -pgo (profile guided optimization), qui permet de filer un jeu d'entrée représentatif pour ton programme et qui permet à icc d'optimiser les branchements en fonction de ce que tu lui donnes. Évidemment, si le jeu d'entrée varie énormément en production, cette option n'est pas très utile…

Le seul succès d'un langage fonctionnel que je connais en HPC, c'est la bibliothèque FFTW. C'est une excellente bibliothèque pour calculer des transformées de Fourier rapide. Ils ont utilisé OCaml non pas pour la bibliothèque mais pour générer du code C qui constitue la bibliothèque.

Euh, tu es sûr pour OCaml? Dans mes souvenirs, Matteo Frigo avait utilisé Cilk pour écrire FFTW…

Mmmh. Self-EDIT: après avoir parcouru le papier sur FFTW, il semblerait que j'ai eu tort, et il utilisait OCaml 2.0 ou 2.1…

Tout dépend de ce qui est demandé de faire en maths. À moins de demander d'analyser une fonction de type la plupart du temps, on demande aux élèves de calculer des trucs un chouïa plus compliquées. La calculatrice est là principalement pour aider l'élève à vérifier qu'il ne se goure pas.