lasher a écrit 2738 commentaires

L’équipe dont je faisais partie se spécialise dans la création d'outils pour la mesure et l'analyse de performance. Ce sont loin d’être des manches. Tout ce dont tu parles, nous le savons bien. ;-) J'ai passé une soirée de rêve avec mon directeur à l’époque à utiliser gdb et essayer de comprendre ce qui se passait avec la MKL (multiplication de matrices) sur Itanium 2.

L’expérience joue un énorme rôle aussi. Faire la course aux cache misses (par exemple) n'est pas toujours payante car on sous-estime d'autres facteurs qui pourraient jouer sur la (non-)performance d'une application.

Pour répondre a ta deuxième question, je fais de la recherche dans une fac aux USA, mais pas en analyse/mesure de performance. Je fais dans les modèles d’exécution pour machines parallèles (c'est a dire : modèle de concurrence, modèle mémoire, et modèle de synchronisation). On implémente tout ça dans un runtime (que j’espère pouvoir libérer très bientôt).

Il fallait comprendre : "30 personnes par type de processeur". :)

Mon expérience sur du multicœur un peu massif (AMD Bulldozer/Interlagos 48 cœurs en mémoire partagée, NUMA, 4×12 cœurs) est contraire à la tienne. Tant qu'il n'y avait pas de frequency scaling et un FSB (sur archi Intel Core 2/Core 2 Quad), tout allait bien en utilisant la bonne version de rdtsc. Le moment où tu as de la variation dynamique de tension et de fréquence, avec en plus plusieurs processeurs reliés entre eux par un réseau d'interconnexion souvent un peu douteux, j'ai appris à mes dépends que rdtsc passait à la trappe (j'ai eu plusieurs fois droit à des comportements très étranges où je me trouvait au final avec un temps négatif, malgré mes précautions …).

Tu as tort. Utiliser rdtsc est parfaitement logique surtout si ton bench prend peu de temps (après tout, les risques de modification de fréquence sont bien moindres). Ça n'empêche pas qu'il faut une certain stabilité. Généralement lorsque je fais des micro-benchmarks, j'utilise un truc du genre:

for ( outer = 0; outer < MAX_OUTER; ++outer) {
    FLUSH_CACHES();
#if OBSERVE_IN_CACHE_BEHAVIOR
    run_kernel(); // warm up caches 
#endif
    uint64_t exec_time = read_rdtsc();
    for (inner = 0; inner < MAX_INNER; ++inner) {
        run_kernel();
    }
    exec_times[outer] = (double) (read_rdtsc() - exec_time) / MAX_INNER;
}
/* ... */

/* exec_times[] contient un « histogramme » des différentes exécutions */
REMOVE_OUTLIERS(exec_times,MAX_OUTER); // supprime les temps les plus courts et les plus longs en fonction de lubies statistiques

COMPUTE_MEAN(exec_times, MAX_OUTER); // arithmétique, harmonique, etc., en fonction des besoins

Note que MAX_INNER/MAX_OUTER peuvent être extrêmement petits dans le cas de microbenchmarks, surtout si l'environnement de benchmarking permet de fixer un thread sur un cœur donné : on évite les variations dues à l'ordonnanceur qui est moins con qu'avant, mais qui va quand même réordonnancer certains threads pour les remettre sur le même cœur juste après… mais avec des caches et TLB qui ont eu droit à des entrées évincées.

Maintenant ce que j'appelle « micro-benchmarks », ce sont vraiment de minuscules benchs, où je teste un sous-système de mon micro-processeur. Genre je veux tester la latence réelle de mon cache L3 partagé : je vais faire tourner 4 threads en parallèle sur mon core i7, un par cœur. Ensuite je vais m'assurer que chaque thread copie un mot de 64 bits dans un registre, puis copie le (i+8×k)è mot dans le même registre à l'itération suivante, etc. J'ai besoin de faire i+8×k car les prefetchers des archis x86 ont tendance à rapatrier la ligne de cache adjacente lors d'un défaut de cache. Du coup il faut précharger au moins tous les 16 mots. L'autre problème étant que, au moins pour les micro-archis Intel, il existe un « stride préfetcher » (« préchargeur de distance » ? je ne sais pas comment traduire). Il détecte tout seul comme un grand si la distance entre deux mots mémoire est fixe. Si c'est le cas, il va précharger les mots mémoire suivants sans qu'on lui demande quoi que ce soit (dans la limite d'une page mémoire, donc pas au-delà de 4096 octets). Du coup il faut faire son sioux, et précharger un mot aléatoire dans la ligne de cache « suivante ».

Soupir…

Désolé pour le HS complet. J'ai pas pu m'empêcher. :)

Bon alors, dans le principe je suis d'accord. En pratique, comme dirait mon ancien directeur de thèse, « il y a peut-être 20 ou 30 personnes dans le monde qui savent réellement quels compteurs utiliser et ce qu'ils font (et ceux qui existent mais qui ne compte pas ce qu'on croit) ».

J'ai fait de l'analyse de performance pendant très longtemps. J'ai mis grosso modo un an à me retrouver avec un tout petit sous ensemble de compteurs qui comptent ce qu'il faut et dont je suis certain de ce qu'ils comptent. Et ce savoir est déjà dépassé : de Core 2/Core Quad on est passé à Nehalem, puis à Sandy Bridge… Ben mon savoir sur Nehalem était déjà à moitié faux (en plus du fait que certains compteurs avaient été renommés, et donc il fallait de nouveau tester ce qu'ils comptaient pour de vrai), et depuis les Sandy/Ivy Bridge, ben il y a peut-être 3 compteurs dont je suis sûr. :-)

Ceci étant dit, j'ai pas fait d'analyse de perf depuis un bail, mais mon directeur (avec qui j'ai causé y'a quelques jours) me disait que comparé aux autres outils existants (HPCToolKit, PAPI, PerfMon), Linuxperf est définitivement le plus fiable, au moins sur x86/Intel (à l'époque j'avais été regarder comment PAPI comptait certains événements dont j'avais besoin, et j'ai remarqué qu'ils prenaient le mauvais compteur… J'ai arrêté d'utiliser PAPI).

Je suis d'accord en ce que la méthodologie me semble peu rigoureuse. Mais en même temps, on peut sans doute faire en sorte de l'améliorer ! :-)

Ta suggestion de faire tout tourner sur un seul cœur les deux versions est à mon avis excellente : même s'il y a une race condition, les effets de bords ne seront pas réellement « visibles » dans le cas non thread-safe.

Les instructions atomiques sont certes plus lentes que des instructions normales, mais elles ont aussi quelques avantages/propriétés. Je vais en citer quelques uns:

1. Une instruction atomique sur x86 actuel (donc Core i5) effectue les opérations suivantes : load-modify-write. Pendant que ceci s'opère, le processeur verrouille la ligne contenant le mot à modifier, et souvent aussi le bus mémoire du cœur qui effectue la modification: le mot est chargé dans un registre, modifié/comparé en utilisant une des UAL du cœur qui a effectué l'op atomique, puis stocké à nouveau en mémoire.
2. Au sein d'un même processeur multi-cœur, lorsqu'on utilise une instruction atomique, seule la ligne de cache qui contient la donnée accédée est verrouillée. Ce qui est important avec ce constat, c'est que le cache lui-même n'est pas complètement verrouillé, et aussi qu'il n'y a pas « d'écriture retour » (write-back) vers la DRAM automatiquement après exécution d'une instruction atomique. Bref, il y a bien sérialisation des écritures/lectures sur une ligne de cache donnée, mais pas sur le bloc/niveau de cache complet (ce qui se faisait à une époque, le bus étant complètement verrouillé pour ce niveau de cache tant que l'op atomique avait lieu).
3. Si jamais tu n'utilises pas d'instruction atomique pour accéder à un mot partagé par plusieurs threads, et que ce mot n'est pas « isolé » tout seul sur sa ligne de cache, tu risques de provoquer un phénomène de faux partage (false sharing), c'est-à-dire que le mot est modifié et du coup indique que la ligne entière est modifiée. Si par hasard d'autres données étaient utilisées en lecture ou écriture par un autre thread sur un autre cœur (en L2 par ex), la ligne devient marquée invalide alors qu'en fait c'était pas le cas. Je ne sais pas si c'est ce qui se passe, mais il arrive qu'en induisant des délais supplémentaire, une opération « lisse » les effets de contention sur un certain composant mémoire (je ne sais pas si je suis clair).

Dans tous les cas, comme on te le faisait remarquer plus haut, si tu ne fournis pas ton code, on ne peut que spéculer.

clock_gettime() est la bonne fonction à appeler en effet. Avec l'option CLOCK_REALTIME si je me souviens bien.

En pratique sur un mono-socket multi-cœur comme décrit pas steckdenis, RDTSC reste OK.

Une autre façon de mesurer (avec rdtsc ou clock_gettime ou gettimeofday …) est simplement d'enrober le programme dans un thread que tu forces à s'exécuter sur un cœur donné, et lui laisser le soin d'appeler le reste du programme. Ensuite, tu peux utiliser des trucs genre pthread_barrier_* ou autres machins faits maison pour garantir que tous les threads sont synchronisés puis reprendre la mesure depuis le threads « launcher ».

Bon on va sans doute m'expliquer que je fais du code moche, mais qu'y a-t-il de mal à faire ce qui suit?

# on sait que le fichier contient que des entiers
current_line = int ( file_descriptor.readline() )

Certes si jamais le fichier ne contient pas que des entiers, ça va casser, et donc au moment de debugger, il faudra séparer la ligne en deux. Mais bon de toute manière le bug existera même avec les deux lignes initiales.

Bon, j'ai fait un IUT. Pendant mes 2 ans a l'IUT, j'ai (je melange les deux annees):

1. Fait de l'algorithmique en C (en utilisant Visual Studio);
2. fait de la programmation événementielle en Visual Basic (avec VS aussi);
3. fait du C++ (la partie OO, pas de STL ou de templates);
4. fait du Java (en utilisant VisualAge a l’époque; d'autres faisaient du C++ plus avance a la place);
5. fait du XML et du XSL/T (d'autres faisaient du COBOL a la place);
6. fait de l'ASP (avec VS; d'autres faisaient du C++…);
7. fait du SQL (sur de l'Access et de l'Oracle).

En plus de cela, j'ai vu (je mélange encore les deux années):

1. De l'architecture des ordinateurs (de l'électronique numérique aux multi-processeurs, en passant par la façon dont les registres et la mémoire fonctionnent);
2. comment les principales fonctions d'un OS fonctionnent;
3. comment faire un makefile portable pour windows et linux;
4. les protocoles réseau (OSI, ethernet, TCP/IP, un tout petit peu de X25/frame relay);
5. comment faire de la prog système;
6. les bases de l'administration sous Linux et Windows;
7. comment concevoir des systèmes d'info avec le génie logiciel (aaaah, Merise et UML …);
8. comment modéliser des bases de données.

A cela s'ajoutent l'Anglais, les cours de communication et expression, les maths, la gestion et organisation, etc.

Bref. Les cours de système et environnement de programmation sont ceux qui m'ont appris comment la chaine de compilation se faisait en C. Je ne sais plus si j'ai vu comment on chaîne en Java en ligne de commande a l'époque, mais je suis certain qu'on m'a explique comment le système de packages fonctionnait.

Tout ça pour dire quoi ? En IUT, les profs on deux ans pour transformer des étudiants qui pour plus de la moitie (je dirais facilement les 2/3, voire les 3/4) ne savent pas réellement ce que signifie "faire de l'informatique" au moment ou ils arrivent en techniciens qualifiés. Ils n'ont pas toujours le temps de tout faire. Dans mon cas, le prof de Java était bien trop occupe a essayer de nous inculquer les principes de POO que nous n'avions qu'effleure en 1ere année en C++ (les trucs genre aller un peu plus loin dans la prog générique, l'overloading et le polymorphisme, la réutilisation de composants, etc.).

Comme tu le dis quelque part, compiler en Java ou en C c'est grosso modo la même chose. Tu as déjà appris la chaîne de compil en C. Pourquoi se faire chier a passer du temps a te faire passer par un shell alors que y'a tellement d'autres trucs a t'expliquer ?

Le departement de l'energie US (enfin, sa division calcul/informatique) met pas mal d'efforts sur l'utilisation de DSL pour correctement exploiter les machines massivement paralleles.

Le probleme c'est l'absence de volonte des utilisateurs/programmeurs d'essayer ces langages d'une part, et l'absence de "dialogue" entre les concepteurs des langages et leurs utilisateurs d'autre part.

Bon, je vais répéter ce qu'un pote m'avait dit il y a longtemps (~10 ans je pense) : il y a les bonnes écoles, et les "écoles de merde". Lui venait d'une école mieux cotée que la mienne, mais qui n’était en gros ni Normale, ni Centrale, ni l'X, ni les Mines, ni… Par contre mon pote enchaînait pour dire : "mais au final sauf pour certaines structures très précises, on s'en fout; ce qui compte, c'est la compétence." Et de m'expliquer que son collègue, lui, venait d'une "bonne" école mais qu'ils avaient la même paie (a noter qu'ils bossent tous les deux dans l’aérospatiale).

Je me suis fait pas mal de potes en école d’ingénieur. Parmi eux, deux de mes potes estimaient que vraiment, notre école, c’était un truc de charlatans, et que regarde ce qu'ils font a l'X, ça au moins c'est couillu. Ce a quoi plusieurs d'entre nous répondaient:

1. Ben t'avais qu'a tenter d’intégrer l'X, pourquoi t'as pas essaye ?
2. En fait, tu ne te rends pas compte que c'est toi qui a un niveau bien supérieur a la moyenne des gens (ces deux potes sont réellement des têtes).

Bref : être ingénieur, ce n'est pas être super-technicien. En informatique cependant, un ingénieur et un technicien (niveau DUT/BTS) sont souvent capables de faire le même boulot. Je viens aussi d'IUT, et l'un de nos profs nous avait dit un jour : "Vous savez quelle est la différence entre un ingénieur et vous en programmation ? Rien. Ah si, le salaire. … Bon en fait, il y a aussi le fait que quand vous faites ce qu'on vous demande et que ça ne marche pas, l’ingénieur doit essayer de trouver une solution." (et en pratique le technicien doit faire de même bien sur, mais c'est plus "implicite").

Enfin, je vais parler de la thèse et de ses débouchés en informatique. Je connais bien, il se trouve que je suis chercheur dans une fac aux USA.

1. OUI, les années de thèse sont des années d’expérience a mettre sur le CV ! Merde, j'ai pas passé 4 ans de ma vie à implémenter des transformations pour compilos, à optimiser des codes industriels qui ont réellement amélioré la vie de certains éditeurs de logiciels, etc., pour ne pas le mettre dans mon CV !
2. Je n'ai pas eu a y aller, mais il est souvent recommande d'aller aux "doctoriales". On y rencontre des thésards de tous horizons (même ceux qui font une thèse qui "ne sert a rien"), mais l'un des thèmes récurrents est comment vendre son doctorat. Entre autres en expliquant qu'on est autonome, qu'on sait ou chercher l'information, mais qu'on sait aussi faire preuve d'initiative, etc. Je blague souvent en disant qu'on sait qu'on est prêt a soutenir quand on connait aussi bien (voire mieux) l'administration que les secrétaires. :-)
3. Au moins en informatique, et dans le domaine de la programmation concurrente, parallèle, du calcul intensif, etc., il y a un large éventail de boites qui recrutent des ingénieurs. Les clusters de 10-50 mille cœurs restent souvent réservés aux grands centres de calcul, mais par contre les clusters "moyens" (~4000 cœurs) sont achetés par plusieurs grosses boites dans divers domaines (pétrolier, cosmétiques, nucléaire, embarqué, etc.).
4. En informatique, pour peu qu'on ne parle pas d'un truc purement théorique, pas mal de grosses boites commencent a comprendre l’intérêt d'un docteur, au moins (encore une fois) dans le domaine du parallélisme et de la concurrence, ainsi que du distribué.

Il n'y a aucune honte a avoir passé du temps a faire une thèse et à le dire dans son CV; c'est juste une question de savoir présenter cette expérience.

Ah oui ? Sur quel site ? C'est un lenovo ?

Moonlight ne permet pas du tout d'accéder aux contenus Netflix. Si c'était (facilement) faisable, je ne streamerais pas depuis ma PS3…

Ben écoute, ils ne se gênent pas pour refuser de diffuser en France les séries de Netflix (même si tu paies) parce qu'ils n'ont pas les droits pour — souvent parce qu'une chaîne FR a déjà des droits exclusifs sur ces séries, ou aussi parce qu'acheter les droits des séries en Amérique du Nord c'est une chose, mais acheter les licences pour tous les pays c'en est une autre niveau prix. S'ils obéissent à la loi des copyrights, etc., pour ce genre de choses (qui donc se font pays par pays), pourquoi n'obéiraient-ils pas à la loi Française quand il s'agit de VOD ?

Rush Limbaugh ne faisait pas partie des 6 hommes. C'est un chroniqueur ultra-conservateur débile.

Honnêtement, tu crois vraiment que 6 hommes, qui n'ont donc, par définition, aucune expérience pratique et directe de la nécessité (ou pas) de prendre la pilule¹, qui plus est tous d'un certain âge, voire d'un âge certain, auront la même « empathie » (ce n'est pas le mot exact que je recherche) vis à vis de la nécessité de certaines à prendre la pilule ?

Je suis désolé, mais ne pas inclure au moins une femme, mais y rajouter 2 figures religieuses à la place, je ne vois pas en quoi c'est pertinent. Et je ne suis même pas certains qu'ils soient crétins, note bien; juste pas forcément correctement au courant de tous les faits (alors qu'une femme du « même niveau » politique et même à la limite religieux l'est forcément plus).

[1] Je rappelle qu'elle est aussi prise pour réguler les hormones chez certaines femmes, et que le côté contraceptif est dans ce cas un effet de bord.

On pourrait aussi dire le logiciel est libre si tu peux lire le code source, mais t'as pas forcément le droit de le modifier et de le redistribuer … Hein, quoi ? Qu'est-ce que j'ai dit ?

Un exemple simple sur le fait que le sexe est important. Aux USA en ce moment il y a une recrudescence de gens qui disent qu'avec « Obamacare » (une sécu au rabais, mais qui permet quand même de garantir un certain niveau d'assurance maladie), un patron est obligé de permettre à ses employés de se faire rembourser la pilule même si sa foi (celle du patron) va contre la contraception. Et donc ils voulaient faire voter un amendement pour permettre aux patrons de choisir (en gros) quels types de médicaments/soins (par ex un avortement) une femme peut se faire rembourser.

La commission qui a étudié cette polémique était composée d'un pasteur, d'un rabbin, et de 4 (je crois) autres hommes. Seule UNE femme, une étudiante en droit, est venue témoigner et expliquer que le coût de la pilule n'est pas anodin, et elle s'est fait ensuite traiter de pute par Rush Limbaugh (un des plus incroyables crétins conservateurs ultra-réacs).

Après, il faut différencier les féministes. Il y en a qui se battent pour l'égalité des sexes, et il y en a qui se battent pour un inversement de la tendance.

Non. http://egalitariste.net/2013/02/25/deconstructions-des-cliches-les-plus-courants-au-sujet-du-feminisme/.

Aussi, certaines féministes nient le rôle de la femme dans sa soumission. Pourtant, dans le modèle contre lequel elles se battent, ce sont les femmes qui éduquent les enfants… Qui deviennent sexistes.

Je ne suis pas d'accord. Le modèle vient des deux (père — quand il est encore là — et mère). La mère fait toutes les tâches « ménagères » dans le modèle que tu évoques, cependant le père est aussi dans le coin, perpétuant le modèle de l'homme fort et de la femme soumise.

Ceci étant dit, il est évident (et je renvoie à la FAQ donnée plus haut pour ça) que le sexisme, de par sa nature de construction sociale, envahit tout, y compris les esprits des femmes. Mais c'est le résultat de siècles et de siècles d'endoctrinement.

Les responsables ne sont pas les hommes, ou les femmes, pas même certains hommes et certaines femmes.

Bien sûr que si. En tant que groupe de femmes et d'hommes, bref de la société, ces inégalités se perpétuent. Et c'est justement lorsque suffisamment d'individus en prennent conscience (et en particulier ceux qui se rendent compte qu'ils sont victimes de ces inégalités) que quelque chose est possible.

Quand on reproche aux féministes d'être l'une des raisons du sexisme, on ne se réfère qu'à une partie de la population féministe, celle qui gueule fort et sans réfléchir. Comme quand on dit que les musulmans sont tous extrémistes, que les juifs essayent de supprimer la liberté d'expression, etc.

Bref, en supprimant la nuance, on démolit complètement le message qu'on voulait passer. Si tu dis que tous les musulmans sont extrêmistes, mais qu'en fait tu voulais dire « certains musulmans sont extrêmistes », ce n'est pas une erreur d'expression anodine. Les mots sont importants. Sinon je te traitais de sale enculé, ben en fait non, je ne te traitais pas d'homosexuel comme si c'était une insulte, et en fait non, je ne pense pas qu'être homosexuel soit grave, mais tu comprends, c'est juste une façon de s'exprimer, il ne faut pas y voir de sens caché …

(je ne sais pas si je suis clair sur la fin de ce paragraphe ;-))

Bon, pour être un grand consommateur de comics, j'ai quand même envie de répondre un chouïa. :-)

1. Oui, les comics de super-héros ont tendance à donner un physique ultra-athlétique aux hommes (« viril » si tu veux), et une attitude super « sexy » aux femmes.
2. Ceci étant dit, les femmes dans les comics, malgré leur apparence, sont passées du statut de « princesses à sauver » (histoire de lier avec l'histoire de « tropes in women… »  ;-) ) à celui de femmes fortes qui sauvent le monde (Wonder Woman¹, Witchblade, Lady Death, les filles de Gen13).
3. Le domaine de la BD US est l'un des média les plus paradoxal que je connaisse : d'un côté l'hyper sexualisation de ses protagonistes est évidente, de l'autre c'est sans doute l'un des endroits où la promotion de l'égalité des genres (hétéros, LBGT) est la plus prononcée.

Je pourrais faire de l'ad lib sur ce sujet, mais si je reconnais volontiers le caractère sexiste de certaines aspects des comics, il ne faut pas oublier les autres aspects, qui eux sont parfaitement égalitaristes.

[1] Je vous encourage tous à vous renseigner sur le personnage. Vous y apprendrez deux choses: (1) Son papa était l'inventeur du détecteur de mensonge (ce qui explique le lasso), et (2) il était féru de bondage/SM (ce qui explique le lasso, ainsi que le contenu des premiers numéros).

Tu parles de l'inverse comme si les proportions étaient les mêmes. Pour prendre une analogie : il y a clairement plus de gens d'origine maghrébine qui sont victimes de racisme que l'inverse. Ça n'empêche pas certains maghrébins d'être racistes (même pas forcément envers les blancs, parfois les noirs, etc.). Ça ne rend la chose ni égalitaire, ni moins mauvaise. Pareil pour les femmes qui traitent les hommes comme des objets.

Je suppose que c'est ironique, mais justement dans ce cas précis, c'est l'exemple d'un mot qui réellement n'a de sens « sexuel » que pour une certaine frange de la population (« lettrée »). Pour tous les autres, ce n'est réellement qu'une insulte (ce qui contraste fortement avec « pédé » ou « enculé » évoqué plus haut).

Dans la fac (US) où je bosse, les RH et « payroll » sont différenciés mais situés dans les mêmes bureaux. Et il y a clairement des gens des RH qui sont aussi « payroll ».

C'est une façon de le voir oui. :-) Quelles que soient les raisons qui font qu'on attend d'un homme qu'il fasse plus d'heures et de la femme qu'elle s'occupe des gosses et donc qu'il soit normal qu'elle parte plus tôt, le problème est bien qu'il y a des attentes implicites sur les capacités au travail en fonction du genre.

Alors il faut pas non plus vivre dans le monde des Bisounours, et bien entendu, les biais existants font qu'on ne peut pas complètement faire abstraction des mœurs courantes (qui, oui, ont tendance à favoriser la mère plus au foyer que le père), mais après tout, lorsqu'on ouvre un poste, il suffit de bien expliquer les responsabilités et les risques d'heures sup' (qui devraient être claires dès le départ si on a un boulot de type « cadre »). À l'inverse, pour un père de famille, dire à son patron « ben ouais, ma femme a aussi une carrière, c'est à moi de m'occuper de la p'tite ce soir pendant qu'elle fait sa garde¹ » ça se fait très bien si on a un patron pas trop con (j'ai pas de stats, mais un ensemble d'exemples autour de moi où le patron au début fait la gueule, mais se rend assez vite compte que les gens qui font ça ne foutent pas rien au boulot : ils bossent bien, et ce serait con de les faire chier parce que désormais ils ont une famille). Et surtout, ça n'empêche pas d'embaucher une nounou/babysitter pour les coups de bourre simultanés pour des conjoints — et le patron généralement saura apprécier les efforts.

[1] Oui, c'est tiré d'un exemple concret, où le mari est ingé, et la femme est interne à l'hôpital…

2°/ Ces métiers moins bien payés compensent souvent avec d'autres avantages : sécurité de l'emploi, horaires moins stressant, contact humain, etc. Nos métiers mieux payés sont souvent aussi plus précaires ou plus dépendant de la conjoncture (combien ici ont souffert de la crise de 2003-2004, où il était considérablement plus difficile de trouver un emploi dans notre domaine ?). Accessoirement, le fait qu'un homme quitte le boulot à 18h pour aller chercher ses gosses sera souvent plus mal vu que dans le cas d'une nana, car on attend davantage d'eux en terme d'implication…

(L'emphase est de moi) Et tu ne vois pas un problème avec ça ?