lasher a écrit 2753 commentaires

Le lien que j'ai donné parlait presqu'uniquement du téton masculin pour servir plus ou moins de tétine, mais en fait je pensais plutôt à ça.

Mmmh. 1600 hommes en fait, pas 16000. Oups.

Au contraire, je trouve l'approche très « scientifique » : on change une variable, et on laisse le reste de l'environnement tel quel. Il est plus facile de mettre en évidence quelque chose si on s'en tient à ne changer qu'un seul aspect (significatif) de ce qu'on veut étudier/changer.

et c'est sexiste de dire que l'homme a des chromosome xy et la femme xx, de dire que l'homme produit de la testostérone et que pour la femme c'est oestrogene et progesterone? Ou ca aussi c'est du à notre "carcans judéo-chrétien"?

Un homme sur vingt mille a des chromosomes XX. En considérant la population française de ~65 millions de gens, et en considérant qu'il y a ~50% d'hommes en France, ça nous fait : 32×10⁶ / (2×10⁴) = 16000 hommes en France en moyenne ont des chromosomes XX. Certes, rapporté à la population globale c'est pas grand chose, mais en nombre absolu ça reste un très grand nombre (et je ne parle pas des gens qui sont XXY).

La testostérone, l'œstrogène, etc., sont produites en quantités différentes par les individus, et oui en pratique, les hommes produisent une quantité supérieure de testostérone que les femmes (mais cette dernière n'est pas forcément produite en quantité nulle par les femmes), et inversement pour l'œstrogène (avec la même remarque).

Ce point de chipotage étant fait, il n'a jamais été affirmé que les différences biologiques entre hommes et femmes n'existaient pas. Ce qui est dit par contre, c'est que ces différences biologiques (génétique, production hormonale, etc.), n'ont pas été démontrées comme ayant une influence significative sur les populations en générale concernant les comportements sociétaux. En d'autres termes, oui un individu ayant un taux de testostérone plus élevé que la moyenne risque d'être plus agressif que la moyenne, mais ça ne veut pas dire qu'il va pour autant choisir l'informatique aux dépends de la broderie comme activité professionnelle (pour prendre deux types d'activités très stéréotypées et qui sont souvent considérées comme étant pour « homme » ou pour « femme »).

Je ne discute pas le fait que le terme « WAF » est effectivement sexiste par essence. Par contre, lorsque tu dis :

Avec WAF, cela donne l'impression que les hommes veulent faire un choix légitime, mais, à cause de leur femme, se voient restreint.

Je comprends comment on pourrait l'interpréter comme ça, mais dans le contexte de ce que Jeff avait décrit, ce n'était clairement pas le cas : il admettait volontiers que c'était lui qui allait d'un certain côté se faire plaisir et foutre le bordel dans la foulée, et donc il cherchait un moyen de minimiser ledit bordel dans un souci de compromis.

Les recherches récentes invalident la notion que les hommes chassaient et les femmes cueillaient dans les cultures plus « primitives » (je mets des guillemets car il existe encore des groupes d'humains qui continuent à vivre ainsi). Les hommes et les femmes étaient en réalité à égalité en ce qui concernait la chasse et la cueillette.

Montre moi un homme qui peux allaiter de facon naturelle et je dirait aussi que les hommes sont fait pour.

Voilà

D'accord, mais même pour les langages qui sont standardisés mais pas forcément normés (genre Java), le créateur (Sun/Oracle) définit une spec quelque part, y compris ce qui compte comme la bibliothèque standard. Qu'Apple s'arrange pour que ses compilos aient une compatibilité facilitée pour passer de Objective-C à Swift c'est très bien. Que MS s'arrange pour que les WinForms marchent bien avec .Net c'est très bien. Tant que la bibliothèque standard officielle est officiellement implémentable sans passer par une plate-forme spécifique, moi ça me va.

Un langage de programmation, c'est une syntaxe qui permets de donner des ordres à un machine.
Une bibliothèque (ou library en anglais) c'est un ensemble de raccourcis permettant de donner des phrases à une machine.

Pas tout à fait. Si un compilateur annonce qu'il se conforme à la norme C11, ça signifie non seulement qu'il va compiler les constructions du langage C (révision de 2011), mais aussi qu'il connaît la bibliothèque standard et fournit une implémentation (qui peut être repompée d'ailleurs, mais ce n'est pas le problème).

Donc si un compilateur annonce qu'il compile de l'Objective-C, je m'attends à ce que ce qui est considéré comme la bibliothèque standard d'Obj-C soit aussi fournie par le compilateur, sinon l'implémentation est incomplète.

C'est pourtant exactement ce qui se passe dans les domaines technologiques pour les allocations de bourses de voyage pour les conférences etc. dans mon domaine (calcul haute-performance, compilation, programmation parallèle): puisque désormais aux USA une bonne partie des thésards sont indiens ou viennent d'Asie (principalement de Chine), alors les « blancs » (je reprends le terme utilisé dans les questionnaires) sont considérés comme une minorité. L'erreur que font beaucoup de gens, c'est de croire que les critères de discrimination positive ne sont pas réévalués pour tenir compte des populations auxquelles ils bénéficient.

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.